Page 1
TTaabbllee ddeess mmaattiièèrreess
Introduction générale ...................................................................................................................... 8
Chapitre.1 Présentation générale ............................................................................................. 11
1.1 Introduction ................................................................................................................... 11
1.2 Présentation de l’organisme d’accueil ........................................................................ 11
1.3 Problématique ............................................................................................................... 12
1.4 Solution proposée ......................................................................................................... 12
1.5 Conclusion .................................................................................................................... 13
Chapitre.2 Etat de l’art ............................................................................................................. 15
2.1 Introduction ................................................................................................................... 15
2.2 Etude comparative ........................................................................................................ 15
2.2.1 Interopérabilité ....................................................................................................... 15
2.2.2 SOA ......................................................................................................................... 15
2.2.3 Deux vues d’intégration L’EAI et L’ESB ............................................................ 16
2.2.4 Comparaison entre Les EAI sur le marché ........................................................... 27
2.3 Choix de méthodologie : .............................................................................................. 31
2.3.1 Comparaison entre les différentes méthodologies ............................................... 31
2.3.2 Choix de méthodologie .......................................................................................... 33
2.3.3 2TUP ....................................................................................................................... 33
2.4 Conclusion .................................................................................................................... 34
Chapitre.3 Spécifications et analyse des besoins .................................................................... 36
3.1 Introduction ................................................................................................................... 36
3.2 Etude préliminaire ........................................................................................................ 36
3.2.1 Cahier des charges : ............................................................................................... 37
Page 2
3.3 Branche fonctionnelle .................................................................................................. 41
3.3.1 Capture des besoins fonctionnels .......................................................................... 41
3.3.2 Analyse ................................................................................................................... 58
3.4 Branche technique ........................................................................................................ 64
3.4.1 Capture des besoins techniques ............................................................................. 64
3.4.2 Conception générique ............................................................................................ 69
3.5 Conclusion .................................................................................................................... 84
Chapitre.4 Conception .............................................................................................................. 86
4.1 Introduction ................................................................................................................... 86
4.2 Conception préliminaire ............................................................................................... 86
4.2.1 Vue dynamique du système ................................................................................... 86
4.2.2 Vue statique de système ......................................................................................... 90
4.3 Conception détaillée ..................................................................................................... 93
4.3.1 Les Design patterns ................................................................................................ 93
4.3.2 Vue dynamique de système ................................................................................... 95
4.3.3 Vue statique de système ....................................................................................... 104
4.4 Conclusion .................................................................................................................. 108
Chapitre.5 Réalisation ............................................................................................................ 110
5.1 Introduction ................................................................................................................. 110
5.2 Environnement du travail ........................................................................................... 110
5.2.1 Environnement matériel ....................................................................................... 110
5.2.2 Environnement logiciel ........................................................................................ 110
5.2.3 Architecture de la solution ................................................................................... 111
5.3 Principales étapes de réalisation ................................................................................ 113
5.3.1 La phase de préparation ....................................................................................... 113
5.3.2 La phase de développement ................................................................................. 113
Page 3
5.3.3 La phase d’intégration.......................................................................................... 118
5.4 Les problèmes rencontrés........................................................................................... 119
5.5 Quelques aperçus ........................................................................................................ 119
5.6 Chronogramme ........................................................................................................... 123
Conclusion générale .................................................................................................................... 124
Page 4
LLiissttee ddeess ffiigguurreess
Figure 1:Architecture de l’EAI .................................................................................................... 18
Figure 2: Les architecture d’un EAI ............................................................................................ 20
Figure 3: L’ESB dans l’entreprise ............................................................................................... 21
Figure 4: L’architecture d’un ESB ............................................................................................... 24
Figure 5: Evolution des technologies d’intégration .................................................................... 24
Figure 6 : Comparaison entre les différents produits sur le marché .......................................... 30
Figure 7 : Projection d’XP et de 2TUP sur la matrice du RUP .................................................. 32
Figure 8 : Les phases de processus 2TUP ................................................................................... 34
Figure 9 : Situation de l'étude préliminaire dans 2TUP .............................................................. 36
Figure 10 : L’interaction entre Biztalk et les différents composants ......................................... 38
Figure 11 : Diagramme de contexte dynamique 1/2 ................................................................... 40
Figure 12 : Diagramme de contexte dynamique 2/2 ................................................................... 41
Figure 13: Diagramme de cas d’utilisations de gestion de mails ............................................... 43
Figure 14 : Diagramme de cas d’utilisation de gestion de calendrier ........................................ 44
Figure 15 : Diagramme de cas d’utilisation d’envoie d’un fax .................................................. 45
Figure 16 : Diagramme de cas d’utilisation de gestion des contacts ......................................... 46
Figure 17 : Diagramme de cas d’utilisation d’envoie d’un SMS ............................................... 47
Figure 18 : Diagramme de cas d’utilisation de gestion du disque virtuel ................................. 48
Figure 19 : Diagramme de cas d’utilisation de gestion de notes................................................ 49
Figure 20 : Diagramme de cas d’utilisation de gestion des applications................................... 50
Figure 21 : Diagramme de cas d’utilisation de participation dans forum ................................. 51
Figure 22 : Diagramme de cas d’utilisation de gestion des documents ..................................... 52
Figure 23 : Diagramme de cas d’utilisation de consultation d’actualités .................................. 53
Figure 24 : Diagramme de cas d’utilisation de discuter avec la messagerie instantanée ......... 54
Figure 25 : Diagramme de cas d’utilisation de gestion des tâches ............................................ 55
Figure 26 : Diagramme de classes participantes ......................................................................... 56
Figure 27 : Le découpage en paquetages ..................................................................................... 59
Page 5
Figure 28 : diagramme de classe des utilisateurs et groupes ...................................................... 60
Figure 29 : Situation de la capture des besoins techniques dans 2TUP..................................... 64
Figure 30 : L’interaction d’un EAI avec les différentes applications, serveurs et bases de
données .......................................................................................................................................... 65
Figure 31 : Diagramme de cas d’utilisations techniques ............................................................ 67
Figure 32 : Les composants de Biztalk server 2006 R2 ............................................................. 72
Figure 33 : L’architecture de Biztalk server ................................................................................ 74
Figure 34 : Receive pipeline ......................................................................................................... 78
Figure 35 : Send pipeline .............................................................................................................. 79
Figure 36 : Le framework .NET ................................................................................................... 81
Figure 37: Mécanisme d'envoie d'un mail ................................................................................... 82
Figure 38 : Diagramme de séquence de consultation d’une boite de mails .............................. 87
Figure 39 : Diagramme de séquence de l’ajout d’un contact ..................................................... 88
Figure 40 : Diagramme de séquence d’ajout d’une tâche .......................................................... 89
Figure 41 : Diagramme de classe de gestion de mails ................................................................ 90
Figure 42 : Diagramme de classe de gestion de contacts ........................................................... 91
Figure 43 : Diagramme de classe de gestion de tâches............................................................... 92
Figure 44 : Architecture de Singleton .......................................................................................... 94
Figure 45 : Architecture de façade ............................................................................................... 95
Figure 46 : Diagramme de séquence détaillé de consultation des mails ................................... 95
Figure 47 : Diagramme de séquence détaillé de l’ajout d’un contact ........................................ 97
Figure 48 : L’orchestration de l’ajout d’un nouveau contact ..................................................... 98
Figure 49: Un cas de mapping...................................................................................................... 99
Figure 50 : Diagramme de séquence détaillé d’importation d’une liste de contacts .............. 100
Figure 51 : Diagramme de séquence détaillé d’ajout d’une tâche ........................................... 101
Figure 52: l'orchestration des tâches .......................................................................................... 103
Figure 53 : Diagramme de classe détaillé de gestion de mails................................................. 104
Figure 54 : Diagramme de classe détaillé de gestion de contacts ............................................ 106
Figure 55 : Diagramme de classe détaillé de gestion de tâches ............................................... 108
Figure 56: Architecture de la solution ....................................................................................... 111
Figure 57: Diagramme de déploiement ..................................................................................... 112
Figure 58 : Interface d’authentification ..................................................................................... 120
Page 6
Figure 59 : Interface de gestion de mails ................................................................................... 120
Figure 60 : Interface d’affichage de mail .................................................................................. 121
Figure 61 : Interface de gestion de contacts .............................................................................. 121
Figure 62 : Interface d’exporter et importer les contacts .......................................................... 122
Page 7
LLiissttee ddeess ttaabblleeaauuxx
Tableau 1: Les fonctions d’un EAI .............................................................................................. 19
Tableau 2 : Les fonctionnalités d’un ESB ................................................................................... 23
Tableau 3 : Comparaison entre ESB et EAI ................................................................................ 26
Tableau 4 : Evolution parallèle des ESB et des EAI .................................................................. 27
Tableau 5 : Vue sur le marché des solutions SOA en 2006 ....................................................... 28
Tableau 6 : Comparaison entre les différents EAI sur le marché .............................................. 29
Tableau 7 : Comparaison entre les différentes méthodologies .................................................. 32
Page 8
Introduction générale
De nos jours, les informations sont de plus en plus dispersées, les systèmes pour les gérer de
plus en plus hétérogènes et complexes. Chaque entreprise adopte sa propre stratégie, par
conséquent, ses propres choix techniques.
Entre systèmes, formats et plates-formes hétérogènes, la communication se trouve souvent
freinée.
Pour faire face à ces freins « technologiques », la réponse la plus simple était de bricoler des
interfaces spécifiques à chaque application et les connecter point à point.
Cette « solution » peut paraître judicieuse quand on parle d’une entreprise dont le système
d’information est simple et indépendant. Mais l’est-elle vraiment quand le système se ramifie,
que les applications se multiplient et que les interfaces croient au fur et à mesure des besoins ?
Va-t-on contourner le problème de la même manière lorsqu’on parlera d’un échange
interentreprises ou inter ministères?
Comme on peut s’en douter, ces bricolages « fait-maison » ne sont en fait qu’un
contournement du problème et non une solution à long terme ou à grande échelle.
L'interopérabilité devient un impératif dès lors que l'on ne raisonne pas à très court terme.
C’est bien dans ce cadre que s’inscrit notre projet de fin d’étude qui consiste en la conception
et la réalisation d’un bureau virtuel. Ce travail ne constitue en fait qu’un cas parmi tant
d’autres dans lesquels on peut appliquer les fondations de l’interopérabilité.
Ainsi, on pourra voir à terme de la conception, une application représentant un bureau virtuel
dont tous les composants sont parfaitement interopérables. Ce qui rendra le bureau virtuel
plus ouvert, extensible et maintenable.
Page 9
Le présent rapport comporte quatre chapitres :
Le premier est consacré à la présentation du cadre générale du projet, l’étude de l’existant, et
le travail demandé. Ensuite nous allons nous focaliser sur les spécifications et l’analyse des
besoins
Dans le troisième chapitre, nous présentons la conception des différents modules de
l’application développée.
Dans le quatrième chapitre, nous décrivons la réalisation de notre application à travers ses
interfaces. Nous donnons aussi un aperçu sur l’environnement de travail de travail et un
diagramme de gant représentant notre avancement au cours du temps.
Page 10
CHAPITRE 1
PPrréésseennttaattiioonn ggéénnéérraallee
1. Introduction
2. Présentation de l’organisme d’accueil
3. Problématique
4. Solution proposée
5. Conclusion
Page 11
Chapitre.1 Présentation générale
1.1 Introduction
Dans le cadre de notre formation d'ingénieurs informaticiens à l’Ecole Supérieure Privée
d’ingénierie et de Technologies, nous avons eu l'occasion d’effectuer notre projet de fin
d'études au sein d’ESPRITec en collaboration avec le Centre National d’Informatique. Le
projet consiste en la conception et la réalisation d’un bureau virtuel dans un environnement
favorisant l’interopérabilité et l’intégration des différents modules.
Dans ce chapitre, nous présentons le cadre général de notre projet, c’est à dire l’organisme
d’accueil : ESPRITec et CNI.
1.2 Présentation de l’organisme d’accueil
Dans cette section nous allons présenter les organismes où nous avons effectué notre projet
de fin d’études.
ESPRITec :
ESPRITec est un organisme fondé au sein d’ESPRIT afin de mener des projets de recherche
en informatique et en télécommunication .
CNI :
Le Centre national d’informatique a comme objectif principal de renforcer la communication
et l’échange électronique au sein de l’Administration publique au niveau central, régional et
local et améliorer l’efficacité de ses services en direction des citoyens et des entreprises en
développant des services à distance.
Le CNI a joué un rôle important dans :
Page 12
La planification et l'organisation du secteur de l'informatique en Tunisie et la
préparation et le suivi des travaux des Plans Nationaux Informatiques (PNI)
La rationalisation de l’acquisition de matériels, de produits et de services
informatiques par l’Administration et les entreprises publiques
Il est important de noter que l’un des principaux champs d’intervention du CNI est
l'administration électronique qui est considérée parmi les objectifs prioritaires du onzième
plan quinquennal de développement économique et social de la Tunisie ( 2007-2011) dans le
domaine des TIC.
1.3 Problématique
L’utilité principale d’un bureau virtuel est de faciliter la vie des employés, de fournir un
nombre de fonctionnalités qui vari selon le poste de l’utilisateur comme la gestion de mails,
gestion de tâches, calendrier partagée…
En effet, le CNI envisage deux chemins pour implémenter ce bureau virtuel, soit elle
développe intégralement la solution soit elle utilise des applications existantes comme une
application qui sauvegarde et liste des tâches assignées. On peut voir que cette solution
présente une fonctionnalité de notre bureau virtuel, donc il dégage de ce qu’il précède que la
deuxième stratégie consiste à communiquer des applications existantes développées en
différents langages avec notre bureau virtuel au lieu de tout développer et on a opté pour ce
choix pour deux raisons, en fait le développement d’une application complète ne sera pas
rentable en terme de temps qui se traduit en perte d’argent pour l’entreprise comme le
développement intégrale peut être condamné à un échec donc pour minimiser les risques
d’échec de l’application on opte pour l’utilisation des fonctionnalités existantes.
1.4 Solution proposée
Pour arriver à nos fins et connecter les différentes applications existantes, serveurs, bases de
données et notre bureau virtuel, nous pouvons penser à connecter ces derniers par des
connexions point à point. Cependant le problème qui se pose dans ce cas est la complexité de
cette architecture, les connexions redondantes, la difficulté de maintenance, la difficulté
Page 13
d’intégrer d’autres applications dans le futur. D’où nous avons pensé à une 2éme alternative
qui comble les défaillances de la première solution et qui consiste à l’utilisation d’un
middleware qui va jouer le rôle d’un serveur d’intégration qui va communiquer tout les
applications hétérogènes, les bases de données et les serveurs et va centraliser le flux passants
entre eux et ajouter des règles métiers sur les données échangés.
En effet, pour des raisons de sécurité le CNI n’a pas pu nous communiquer ses applications
existantes ce qui nous pousse à développer quelques fonctionnalités nous-mêmes sur des
différentes plateformes pour mettre en évidence le rôle prépondérant du serveur d’intégration
dans notre projet. Bien que la finalité de ce projet n’est pas le développement de tous les
modules relatifs au bureau virtuel mais la compréhension et la mise en place d’un
environnement d’interopérabilité permettrait aux sociétés intéressées de tirer profit de
l’application réalisée et l’adapter à ses besoins.
Ainsi au point de vue réalisation, on ne sera pas amené à réaliser tous les modules, la
principale tâche étant l’exploitation du potentiel du middleware dans les quelques modules
réalisés. Malgré que la conception et la réalisation n’aient pas pour but d’être totale, l’analyse
quant à elle doit l’être.
1.5 Conclusion
Ce chapitre nous a servi à mettre le projet dans son cadre. En effet, notre projet de fin
d’études est effectué en collaboration avec le CNI. Il a consisté en l'implémentation et
l’intégration des modules composants le bureau virtuel dans un contexte d’interopérabilité.
Dans le chapitre suivant, nous introduirons des concepts nécessaires à la compréhension de ce
projet à savoir : Une étude comparative entre ESB et EAI ainsi que la comparaison et le choix
de la méthodologie.
Page 14
CHAPITRE 2
EEttaatt ddee ll’’aarrtt
1. Introduction
2. Etude comparative
3. Choix de méthodologie
4. Conclusion
Page 15
Chapitre.2 Etat de l’art
2.1 Introduction
Dans ce chapitre, nous allons présenter quelques notions et quelques technologies qui vont
servir à mieux comprendre notre sujet, d’autre part nous allons fais des études comparatifs
pour justifier nos choix.
2.2 Etude comparative
2.2.1 Interopérabilité
En informatique, l’interopérabilité est la capacité qu’a un système à fonctionner avec d’autres
systèmes existants ou potentiels sans aucune limitation de mise en œuvre ou d’accès. Elle ne
se limite pas au fait que ces systèmes peuvent fonctionner ensemble (dans ce cas on parlera de
compatibilité) mais du fait qu’on sait pourquoi ils le peuvent. Pour ce faire, chaque système
doit avoir une interface qui doit être connue, c'est-à-dire qu’elle suit une (ou plusieurs)
norme(s). Les normes sont ainsi le pilier de base de l’interopérabilité.
2.2.2 SOA
L'architecture orientée services (Service Oriented Architecture en anglais) est une forme
d'architecture de médiation qui est un modèle d'interaction applicative qui met en œuvre des
services (composants logiciels) avec une forte cohérence interne (par l'utilisation d'un format
d'échange pivot, le plus souvent XML) et des couplages externes « lâches » (par l'utilisation
d'une couche d'interface interopérable, le plus souvent un service web WS-*).
Le service est une action exécutée par un « fournisseur » (ou « producteur ») à l'attention d'un
« client » (ou « consommateur »), cependant l'interaction entre consommateur et producteur
est faite par le biais d'un médiateur (qui peut être un bus) responsable de la mise en relation
des composants. Le service étant à grandes mailles, il englobe et propose les fonctionnalités
des composants du système. Ces systèmes peuvent aussi être définis comme des couches
applicatives. L'architecture orientée services est une réponse très efficace aux problématiques
Page 16
que rencontrent les entreprises en termes de réutilisabilité, d'interopérabilité et de réduction de
couplage entre les différents systèmes qui implémentent leurs systèmes d'information
2.2.3 Deux vues d’intégration L’EAI et L’ESB
L’intégration d’applications désigne d’un coté les processus et d’un autre les progiciels
permettant ainsi d’automatiser les échanges entre différentes applications d’une entreprise ou
différents systèmes d’information d’entreprises différentes. Les applications et les entreprises
peuvent donc échanger des données, des messages et collaborer à l’aide de processus
communs.
Les plates-formes utilisées relient les applications hétérogènes du système d’information
autour d’un bus logiciel commun, chargé du transport des données.
Les principaux facteurs poussant au développement de la mise en place de plates-formes
d’intégration dans les entreprises sont:
La composition souvent très hétérogène du système d’information de l’entreprise qui
complique la tâche de maintenance et de communication entre les différents composants,
pouvant même présenter un obstacle dans l’exploitation des données et de potentiel de ces
différents systèmes, d’où le besoin d’une plateforme d’intégration pour faciliter la
communication et la maintenance des passerelles existantes entre ces systèmes.
Les événements ou changements structurels qui poussent les entreprises à augmenter la
flexibilité et la réactivité de leur système d’information, d’où la généralisation des besoins
d’intégration entre les applications de production (ERP) de logistique (SCM) de relation client
(CRM).
La conception de l’architecture du système d’information comme un ensemble organisé et
évolutif de services fortement couplés. L’approche SOA (Service-Oriented Architecture)
redéfinit l’intégration d’applications.
Page 17
2.2.3.1 Une étude comparative entre l’EAI et l’ESB
a- L’EAI
L'Intégration d'applications d'entreprise ou IAE (en anglais Enterprise Application
Intégration, EAI) est une architecture inter logicielle permettant à des applications
hétérogènes de gérer leurs échanges. Sa particularité est d’échanger les données en pseudo
temps réel.
Par extension, l'acronyme EAI désigne un système informatique permettant de réaliser cette
architecture en implémentant les flux inter applicatifs du système d'information [1].
En effet, de nos jours les entreprises ne cessent d’évoluer leurs architectures physique et
logicielle ce qui peut constituer une contrainte pour l’équipe qui doit intégrer le nouveau
composant. Elle doit ainsi développer une interface de mappage entre ce dernier et les autres
points ce qui engendre un gaspillage de temps. De ce fait les entreprise ont eu recours aux
architectures EAI qui présentent un point de connexion entre les différentes entités.
Une solution d'EAI est destinée à intégrer les applications selon un principe de couplage
faible, où les applications peuvent s’améliorer et fonctionner indépendamment les unes des
autres. Un des principaux bénéfices de l’EAI est que l’entreprise peut faire évoluer en douceur
son système d’information en s’appuyant au maximum sur l’existant.
Une plate-forme EAI est construite suivant un schéma standard :
Des connecteurs, servant d'interface entre l'EAI et les applications. Ils scrutent les
évènements de l'application et transmettent les données associées vers l'EAI (ou fournissent à
l'application les données provenant de l'EAI). Ces données sont appelées ASBO (application
specific Business Object) car elles reflètent les données de l'application (nom du champ,
format...). Un connecteur touche généralement à tout ou à une partie des aspects suivants:
authentification, gestion des conversations, contexte de sécurité, transactionnel, gestion des
droits, etc...
Les ASBO qui proviennent (ou dirigées vers) des connecteurs passent par une
opération de Mapping pour convertir les données spécifiques aux applications
(ASBO) en données standards à l'EAI : les BO (Business Object).
Page 18
Les BO réfléchissent ainsi le modèle de donnée global des informations des différents
processus de l'entreprise. Ils sont alors transmis à des opérations appelés
collaborations qui reflètent la logique de traitement à appliquer sur un BO avant de
l’envoyer à une application cible.
Un middleware asynchrone, qui gère la livraison asynchrone garantie des messages sur
les applications connectées au courtier de messages (message broker). Des aspects de
sécurité sont également contrôlés par cette couche.
Un gestionnaire de processus, apte d'orchestrer les échanges de messages inter
applicatifs dans le but d'exécuter des processus métiers. La présence d'un outil de
workflow humain devient de plus en plus une nécessité au sein de l’entreprise.
Un gestionnaire de services, capable d'appliquer des services à valeur ajoutée qui sont du
ressort de l'architecture d'intégration et non du fonctionnel des applications (ex: routage,
transformation de messages, transcodification, etc.)
Un référentiel, responsable de la cohésion et du paramétrage des composants déployés
dans la solution EAI.
Une console d'administration, garantissant la supervision de fonctionnement des
composants techniques de la solution EAI, ainsi que les processus métiers.
Figure 1:Architecture de l’EAI
Page 19
Cette plate-forme d'intégration assure les quatre types de fonctions suivants:
Tableau 1: Les fonctions d’un EAI
Routage Autrement dit, en fonction d'événements préalablement définis,
un logiciel d'Intégration récupère les données d'une application,
puis les routent vers leur destination (une autre application),
après les avoir préalablement converties dans un format adéquat.
A cette fin, il met en œuvre :
- un serveur d'intégration qui comprend un moteur de règles et
un gestionnaire de messages (pour le routage et la
transformation)
- des connecteurs (pour dialoguer avec les applications)
- et un MOM (middleware orienté messages) pour transporter
les messages. Quasiment tous les fournisseurs d'Intégration
disposent de leur propre MOM même si la plupart du temps les
plates-formes d'Intégration sont déployées sur des MOM déjà
installés dans l'entreprise.
Transformation
Connecteurs (aux
applications)
Transport
La gestion des processus métiers (BPM, pour Business Process Management) prolonge les
quatre fonctions de l'Intégration. Le BPM introduit une couche d'abstraction où l'information
traitée n'est plus une donnée ou un flux technique d'une application vers une autre mais un
processus métier. A travers le logiciel de BPM, un architecte métier définit un processus qui
sera traduit en flux techniques, lesquels sont transmis au serveur d'intégration à des fins de
paramétrage. Dans la réalité, ce n'est pas vraiment une surprise, tout n'est pas aussi transparent
et automatique. Passer les informations du BPM au serveur d'intégration demande des
interventions humaines pour, achever le paramétrage technique.
L’EAI peut implémenter l’une des deux architectures suivantes le "Hub and spoke" et le
'Network Centric".
Page 20
L'architecture "Hub and spoke"
C'est le modèle centralisé de l'Intégration. Dans ce cadre tout passe par un "hub" central.
Aucun flux n'est possible sans l’intercession de ce hub. Quand une application envoie un
message, ce dernier est transmis à destination du hub. Le référentiel (la base où sont stockées
les règles de routage et de transformation) est donc lui aussi centralisé. L'avantage d'une telle
architecture saute aux yeux: l'administration est grandement facilitée. En revanche la gestion
de la charge s'avère complexe dans ce type d'environnement: la seule solution consiste en
effet à multiplier les hubs sur les différents segments du réseau, sachant qu'il faudra veiller à
synchroniser les règles stockées sur ces différents nœuds. L'administration devient alors
moins aisée.
L'architecture "Network Centric"
Il s'agit cette fois de la version décentralisée de l'implémentation de l'Intégration. Des
référentiels de règles et des gestionnaires de messages sont distribués sur l'ensemble des
nœuds (point de connexion à une application). Quand une application émet un message, ce
dernier est traité par le référentiel du nœud correspondant afin que les applications abonnées à
ce type de messages le reçoivent. Avec ce type d'architecture, la charge est donc
naturellement répartie sur l'ensemble des nœuds.
On peut voir ici les différentes architectures :
ARCHITECTURE HUB & SPOKE ARCHITECTURE NETWORK CENTRIC
Figure 2: Les architecture d’un EAI
Page 21
Nouvelle vision pour L’EAI :
La prise en compte de systèmes hors de l’entreprise (partenaires, fournisseurs), il s’agit du
support du B2B (Business to Business Integration).
L’utilisation des services Web. Il s’agit de la standardisation de l’utilisation des services
Web, ce qui permet d’y accéder plus facilement depuis n’importe où, rendant plus aisé le
commerce sur Internet.
b- L’ESB :
Un (Enterprise Service Bus) est une solution d’intégration implémentant une architecture
parfaitement distribuée, et fournissant des services comme la transformation des données ou
le routage basé sur le contenu CBR(Content-Based Routing), ainsi qu’une interopérabilité
accrue par l’utilisation systématique des standards comme XML, les Web Services et les
normes WS-*.
L’ESB est une solution packagée qui permet de mettre en œuvre la SOA 1
Figure 3: L’ESB dans l’entreprise
1 Source : Nouvelles technologies pour l’intégration: les ESB EBM Websourcing Janvier 2006
Page 22
D’après M. Roy Schulte de la société Gartner inc, "L'ESB est une nouvelle architecture qui
exploite les services web, les systèmes orientés messages, le routage intelligent et la
transformation. L'ESB agit comme une colonne vertébrale légère et omniprésente de
l'intégration à travers laquelle les services logiciels et les composants applicatifs circulent".
Les ESB sont les héritiers directs des EAI, ils reprennent les particularités architecturales des
solutions d'EAI, les ESB se focalisent sur les fonctions d'interconnexions et de médiation, et
s'appuient pour cela sur un ensemble de standards et respectent certaines mesures parmi
lesquelles on peut citer :
Au niveau de la connectivité, des standards comme les services Web pour gérer les
communications synchrones, J2EE et .NET. Ces solutions de Sun pour J2EE et Microsoft
pour .NET sont les environnements d’architecture distribuée dominants à l’heure actuelle.
J2EE apporte la portabilité du seul langage Java sur de nombreuses plates-formes, alors
que .NET apporte la portabilité de nombreux langages, mais seulement en environnement
Windows sur hardware Intel.
XML pour définir les formats des messages.
Au niveau des transformations, les standards choisis sont XSLT et Xquery.
Au niveau de la sécurité, on s’appuie sur SSL (Secure Socket Layer) et LDAP
(Lightweight Directory Access Protocol). Ce dernier s’appuie directement sur TCP/IP
JMS (Java Message Service) pour adresser la communication asynchrone avec les MOM.
JCA (Java Connector Architecture) pour la connexion aux progiciels et systèmes
exotiques (ERP, CRM, Mainframes, etc.)
Les applications sont déployées selon l’architecture SOA et le déploiement est
grandement facilité, le coût de possession est réduit.
On peut donc dégager de ce qui précède que L’ESB est une plate-forme d’entreprise qui met
en œuvre des interfaces standardisées au niveau des communications, de la connectivité, des
transformations, de la portabilité et de la sécurité.
Synthèse des fonctionnalités
Le tableau suivant synthétise les principales fonctionnalités que l'on peut attendre d'un ESB :
Page 23
Tableau 2 : Les fonctionnalités d’un ESB
Connectivité Supporte de multiples protocoles de transport synchrone ou
asynchrone. Il faut voir l'ESB comme un "super-connecteur". Son
rôle est de se connecter à tout type de ressources ou fournisseurs
de services. C'est grâce à cela qu'il permet une exposition en
couplage lâche de fournisseurs de services.
Routage Permet d'effectuer des routages de message basés sur des règles (de
contenu, de contexte, etc.). Idéalement ce routage s'appuie sur un
annuaire, sur un registre de services et éventuellement sur un moteur
de règles.
Médiation Adapte le format des messages, le protocole, effectue des
transcodifications entre l'appelant et l'appelé.
Exposition de services
Transforme en service(s) un composant ou un traitement d'une
application qui ne le peut pas facilement.
Agrégation simple de
services
Effectue des agrégations simples de services de niveau N pour
construire des services de niveau N+1. Si l'agrégation est complexe on
préférera utiliser un moteur d'orchestration.
Traitement d'événements
complexes
Permet la création des règles de corrélation et de jointure
d'événements.
Contrat de service Permet la définition des contrats de services : SLA, niveau de
QoS, gestion des priorités, sécurisation des messages (signature et
cryptage), garantie de la livraison et de l'intégrité des messages.
Supervision et audit Offre des fonctions d'audit, de traçabilité, de mesure, d'administration
et d'exploitation qui permettent le suivi des traitements. Selon la qualité
de l'implémentation, cette fonctionnalité sera déléguée à un outil tiers.
L'architecture
L'Enterprise Service Bus possède une architecture en bus qui l'oppose à l'architecture hub and
spoke des EAI. Ceci fait de l'ESB une solution hautement distribuée. Les composantes de
cette architecture sont illustrées sur la figure suivante :
Page 24
Figure 4: L’architecture d’un ESB
c- Comparaison entre l’EAI et l’ESB
Dans cette partie, nous allons nous attarder sur les points de convergences et de divergence
des deux technologies : l’EAI et l’ESB.
Pour ce faire, nous commençons par donner un aperçu sur l’évolution des différentes
approches d’intégration depuis les années 80.
Figure 5: Evolution des technologies d’intégration
Les produits de type ESB semblent bien adaptés à l’implémentation de projets EAI de taille
moyenne, concernant des chaînes d'intégration qui impliquent des ressources non critiques. Ils
intéressent également les PME (petites et moyennes entreprises) pour leur faible coût d'achat
Page 25
et les standards qu'ils exploitent, notamment XML, de plus en plus utilisé comme format
d’échange de données au sein des solutions métier. Cependant les ESB présentent des
faiblesses inévitables à l'absence de normes touchant à l'orchestration des processus et la
sécurisation des échanges de flux XML. Avant de faire un choix définitif, il convient de
procéder à un test de performances.
Coût d'achat
Le coût global de la mise en œuvre d'une solution de type ESB reste très inférieur à celui des
solutions traditionnelles d'EAI. Cette économie découle d'une coté des prix relativement bas
pratiqués par les éditeurs d'ESB et d'autre part de l'utilisation de technologies standards, qui
participe efficacement dans la diminution du montant de la facture lorsque l'entreprise fait
appel à des compétences externes pour développer ses projets d'intégration.
Une approche encore en devenir
L'ESB endure de l'absence de normes définitives, précisément en matière de description de
processus (orchestration, gestion des exceptions et des erreurs...) et de sécurité, surtout
lorsque les échanges de données impliquent l'entreprise et ses partenaires. Dans l’attente de
l'arrivée de normes définitives, les éditeurs impliquent des solutions transitoires, une
concession de poids par rapport aux objectifs initiaux de l'approche ESB.
Le respect des standards
Parmi les technologies sur lesquelles repose l'approche ESB, XML est l’un de principaux
standards utilisés. L'adoption de ce langage simplifie les échanges entre l'entreprise et ses
partenaires. L'exploitation des services web facilite l'intégration de composants applicatifs
hétérogènes. Le middleware JMS permet de passer naturellement d'une architecture en mode
point à point à un bus d'échanges fonctionnant en mode dynamique.
L'intégration avec l'existant
L'ESB repose sur un système d'échange de messages éprouvé : le middleware orienté message
(MOM). Les solutions développées en Java, et qui respectent la norme JMS, montrent des
performances répondant aux attentes des entreprises. L'utilisation de JMS en interne par les
différents composants de l'outil ESB constitue également un gage de performances et
Page 26
d'ouverture. Les standards JMS, JCA, services web facilite énormément l'intégration d'un bus
applicatif de type ESB avec un existant, la plupart des éditeurs de produits d'EAI fournissant
déjà des solutions de connectivité compatibles avec ces normes.
Le tableau ci dessous montre mieux les points de différence entre l’EAI et l’ESB
Tableau 3 : Comparaison entre ESB et EAI
L’apparition des ESB, plus adaptés par leur architecture de services à l’évolution vers SOA, a
poussé les éditeurs d’EAI / BPM pour améliorer leurs produits. Ils ont suivi le mouvement en
changeant l’appellation de leurs offres en incitant l’évolution technique de leurs plates-formes
pour prendre en compte les standards (XML, Web Services, JMS, etc.) et répondre à certaines
exigences liées aux architectures SOA comme la virtualisation des services, la sécurisation
des appels, l’équilibrage de charge entre services, etc.
Les ESB aussi ont étalé leur couverture fonctionnelle et offrent ainsi des fonctions
d’orchestration des services, voire de gestion de processus. Quant aux éditeurs de solutions
d’EAI/BPM, ils ont compris l’importance du mouvement d’évolution des Systèmes
d’Information vers les architectures SOA et ont continué d’enrichir leur offre en proposant
des outils de gouvernance SOA.
Page 27
Tableau 4 : Evolution parallèle des ESB et des EAI
2.2.3.2 Choix de Middleware :
Pour conclure, les éditeurs de L’EAI essaient de combler leurs défaillances et ne tardent plus
à adopter l’approche SOA, les web service et les différents standards. Ceci nous pousse à
choisir un EAI pour l’implémentation de notre projet vu la richesse de fonctionnalités comme
le BMP, l’orchestration et la console d’administration offerte ce qui peut nous faciliter la
tâche. Dans la partie suivante nous allons effectuer une comparaison entre les EAI présents
dans le marché.
2.2.4 Comparaison entre Les EAI sur le marché
2.2.4.1 Vue sur le marché
Le Marché de l’EAI décolle avec celui de l’e-business. Les entreprises visent la performance
et la présence continuelle dans le marché ce qui les pousse à développer de nombreuses offres
sur le web. Avec l’accroissement de nombre des services online, l’amélioration de leurs
applications déjà existantes devient indispensable.
Les applications e-business suscitent le besoin d’intégration pour que toutes les informations
restent cohérentes et disponibles.
Page 28
Pour ce motif, les entreprises intègrent leurs applications en achetant les EAI des éditeurs de
logiciels qui voient à leur tour en l’EAI, un marché plutôt prometteur. Ceux-ci passent des
accords de partenariat avec d’autres éditeurs, par exemple Siebel qui a signé un accord
d’intégration avec IBM. D’autre rachètent carrément les éditeurs possédant les applications
manquantes, c’est notamment le cas pour de nombreuses entreprises : Nortel rachète Clarify,
Lucent rachète Mosaix. Ces applications EAI sont ensuite proposées aux entreprises clientes.
C’est alors que les entreprises éditrices commencent à créer leur propre offre globale, comme
par exemple, Sybase Neonsoftare, IBM Crossworlds, Sopra Viewlocity. Une explosion dans
le monde de middleware et l’EAI apparaît en 1999, bien que la notion d’intégration existe
depuis 1997. Selon une étude menée par la Business Intelligence en 1999, 54% des
entreprises estiment qu’avec la croissance de l’e-business, le manque de communication entre
applications leur ferait défaut.
De cette effervescence autour de l’EAI, apparaissent de nombreux acteurs, tels que
SeeBeyond, Tibco …, d’autres éditeurs généralistes comme le cas de Microsoft s’introduisent
dans le marché de l’EAI avec son serveur Biztalk.
Tableau 5 : Vue sur le marché des solutions SOA en 2006
[2]
BEA 60 %
IBM 43 %
Microsoft 31 %
Oracle 30 %
SUN 21 %
SAP 12 %
Tibco 12 %
WebMethods 10 %
Page 29
2.2.4.2 Etude comparative
Vu le grand nombre d’éditeurs de l’EAI sur le marché, nous allons cerner notre choix entre 3
leaders pour choisir le plus convenable entre eux dans notre contexte. Le tableau suivant est
un tableau comparatif présentant les caractéristiques des trois éditeurs étudiés, à savoir :
IBM, Microsoft et Sybase – Neonsoftware :
Tableau 6 : Comparaison entre les différents EAI sur le marché
Websphere process
server ( IBM )
Biztalk (Microsoft ) Unwired orchestrator
( Sybase )
Mise en place et
paramétrage
complexe facile facile
Connecteurs plusieurs plusieurs peu
BPM(business
process management)
intégré intégré Non intégré
Prix 500000 € 39 000 € 125 000 €
2.2.4.3 Choix de L’EAI
L’offre de IBM semble être la solution la plus complète sur le marché, offrant un des
services adaptés à notre projet. Cependant, le prix excessif de produit l’élimine de la liste
(500000€).
Pour ce qui est de l’offre de Sybase, on remarque plusieurs failles au sein de système tels que
le manque de gestion de workflows, la non intégration du MOM dans la Couche transport, le
mode synchrone non permis, pas d’interface graphique pour mapping, peu de connecteur, pas
de notion de profils d’utilisateurs. Tous ces inconvénients nous décourage de l’utiliser.
Finalement, BizTalk propose un middleware riche en fonctionnalités, un grand nombre
Page 30
d’adaptateurs qui assurent la communication avec les composants hétérogènes, une interface
d’administration BAM qui facilite la tâche de contrôle , une gestion complète de processus
(orchestration, mapping…). De plus, il présente la meilleure offre des prix des EAI sur le
marché offrant le prix le plus convenable et il ne cesse d’évoluer.
En effet, BizTalk est nouveau par rapport aux autres EAI produisant depuis 2000 6 versions.
Chacune de ses versions offre plus de fonctionnalités.D’autre part, il s’installe dans nos jours
comme l’un des leaders de EAI et pour des raisons de stabilité que nous avons choisi BizTalk
2006 R2 car le Biztalk 2009 a lancé une version beta. La figure suivante montre l’importance
de BizTalk au sein de marché d’EAI.
Voici un zoom sur le marché de l’EAI :
Figure 6 : Comparaison entre les différents produits sur le marché
Page 31
2.3 Choix de méthodologie :
2.3.1 Comparaison entre les différentes méthodologies
Beaucoup de gens pensent que le développement d’un logiciel se limite à la partie codage. Or
la phase codage est une phase parmi plusieurs dans le cycle de vie d’un logiciel et si on
néglige ces derniers les problèmes et les bugs ne vont pas tarder à flotter sur la surface.
Dès les années 70, le développement de logiciels connaissait des problèmes. Il n'y avait pas de
méthodologie et de norme ce qui donna bien souvent des systèmes de qualité douteuse. Les
systèmes de nos jours sont beaucoup plus évolués que cette période ce qui peut poser des
problèmes graves. Le génie logiciel tente à l'aide de processus, analyse, méthode et norme de
remédier à ce problème. Les dépassements de budget et de temps sont monnaie courante dans
le développement d'application. Voila les principes de base du génie logiciel qui tente de
corriger ces problèmes.
Le but du développement de logiciel est de produire un logiciel de qualité. Plusieurs critères
essaient de définir la qualité d'un logiciel.
De ce fait, nous sommes obligés de suivre une méthodologie de développement pour assurer
une meilleur qualité pour notre logiciel. En effet, ls processus de développement régit les
activités de production du logiciel selon deux aspects.
L’aspect statique qui représente le processus en termes de tâches à réaliser.
L’aspect dynamique qui représente la dimension temporelle du processus.
On va entamer une comparaison entre les différents processus de développement pour choisir
le mieux adapté à notre projet. Vu le nombre important de méthodologies, on va se limiter à
une comparaison entre le RUP, 2TUP et XP qui sont très utilisés dans les entreprises.
Page 32
Tableau 7 : Comparaison entre les différentes méthodologies
Méthodologie Description Points forts Points faibles
RUP Promu par Rational.
Le RUP est à la fois une
méthodologie et un
outil prêt à l’emploi
(documents types
partagés dans un
référentiel Web).
Cible des projets de
plus de 10 personnes.
-Itératif.
-Spécifie le dialogue
entre les différents
intervenants du projet.
-Propose des modèles de
documents pour des
projets types.
-Coûteux à personnaliser :
batterie de consultants.
-Peu de place pour le code
et la technologie.
2TUP S’articule autour de
l’architecture.
Propose un cycle de
développement en Y.
Cible des projets de
toutes tailles.
-Itératif.
-Fait une large place à la
technologie et à la
gestion du risque.
-Définit les profils des
intervenants, les
livrables, les plannings,
les prototypes.
-Plutôt superficiel sur les
phases situées en amont et
en aval du
développement : capture
des besoins, gestion du
changement.
-Ne propose pas de
documents types.
XP Ensemble de bonnes
pratiques de
développement (travail
en équipe, transfert de
compétences…)
Cible des projets de
moins de 10 personnes
-Itératif et simple à
mettre en œuvre
-Fait une large place aux
aspects techniques.
-Innovant:
programmation en duo
-Ne couvre pas les phases
en amont et en aval au
développement : capture
de besoins, maintenance...
-Assez flou dans sa mise
en œuvre
Figure 7 : Projection d’XP et de 2TUP sur la matrice du RUP
Page 33
Cette figure nous montre l’étendue des différentes méthodologies sur le cycle de vie d’un
logiciel. En effet, le RUP traite les différentes phases : les spécifications de besoins, la
conception, le développement et les tests. Le 2TUP néglige un peu la première partie et L’XP
se focalise sur la phase de développement.
2.3.2 Choix de méthodologie
D’après ce tableau comparatif, on a tendance à éliminer le RUP qui néglige la technologie et
les contraintes techniques présentant une grande partie de notre projet. Par ailleurs, on inhibe
l’XP qui néglige, pour sa part, l’étude fonctionnelle et la capture des besoins fonctionnels et
techniques. De plus, une grande importance est accordée dans l’XP au développement aux
dépens de la phase de conception où seront introduites les différentes interactions entre nos
composants et notre middleware.
Par voie de conséquence, nous optons pour le processus 2TUP pour plusieurs raisons. D’une
part il accorde une grande importance à la technologie ce qui nous convient parfaitement,
d’autre part le 2 TUP est une méthode en Y constituée de 2 branches l’une fonctionnelle et
l’autre technique. ces dernières peuvent évoluer en parallèle et s’adaptent facilement à
l’évolution au sein de l’entreprise. En effet lorsque la technologie change ou évolue la
branche technique peut être traitée à part et réintégrée dans le projet. D’autre part, en cas
d’ajout de fonctionnalités à notre projet, la branche fonctionnelle peut être traitée seule sans
toucher à l’autre branche ce qui constitue une méthodologie souple et adaptable aux différents
environnements de travail.
2.3.3 2TUP
Il dégage de ce qui précède qu’on va suivre le processus 2TUP (2 track unified process,
prononcez "toutiyoupi") qui est un processus de développement logiciel qui implémente le
Processus Unifié.
Le 2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques des
aspects fonctionnels. Il commence par une étude préliminaire qui consiste essentiellement à
identifier les acteurs qui vont interagir avec le système à construire, les messages
qu'échangent les acteurs et le système, à produire le cahier des charges et à modéliser le
Page 34
contexte (le système est une boîte noire, les acteurs l'entourent et sont reliés à lui, sur l'axe qui
lie un acteur au système on met les messages que les deux s'échangent avec le sens). Le
processus s'articule ensuite autour de 3 phases essentielles:
Une branche technique
Une branche fonctionnelle
Une phase de réalisation
[3]
[4]
Figure 8 : Les phases de processus 2TUP
2.4 Conclusion
Dans ce chapitre, nous avons passé en revue les différentes notions nécessaires à la
compréhension de notre sujet, et nous avons mené une étude comparative entre les différentes
technologies et les différents produits afin de faire le meilleur choix de notre environnement
de travail. Le chapitre suivant portera sur le processus 2TUP, la méthodologie qui nous
semble la plus adaptée à notre projet.
Page 35
CHAPITRE 3
SSppéécciiffiiccaattiioonnss eett
aannaallyyssee ddeess bbeessooiinnss
1. Introduction
2. Etude préliminaire
3. Branche fonctionnelle
4. Branche technique
5. Conclusion
Page 36
Chapitre.3 Spécifications et analyse des besoins
3.1 Introduction
Dans ce chapitre, nous allons entamer la phase de spécification et d’analyse des besoins. Nous
allons présenter en premier l’étude préliminaire dans laquelle on parcourra le cahier de
charge. Puis on abordera la branche fonctionnelle suivie de la branche technique.
3.2 Etude préliminaire
L'étude préliminaire est la toute première étape de notre processus de développement. Elle
consiste à effectuer un premier extrait des besoins fonctionnels et opérationnels, en utilisant
principalement le texte, ou des diagrammes très simples.
Figure 9 : Situation de l'étude préliminaire dans 2TUP
Dans cette étape on doit définir les entités externes et leurs interactions avec le système.
Page 37
3.2.1 Cahier des charges :
3.2.1.1 Présentation du projet:
Le CNI, centre national d’informatique, est un établissement public qui adopte plusieurs
projets de recherche dont notre projet qui s’intitule bureau virtuel administratif.
Le CNI est constitué de plusieurs départements qui communiquent ensemble, chaque
département ayant ses propres besoins. C’est dans ce cadre que l’idée de création de bureau
virtuel est née. .En effet nous comptons réaliser une interface pour chaque employé où il peut
accéder à ses outils bureautiques, les logiciels dont il a besoin , où il peut sauvegarder ses
documents ou les partager dans l’intranet , communiquer avec les autres employés via un
forum ou une messagerie instantanée, consulter sa calendrier , la modifier selon ses besoins et
même la partager avec ses collègues , utiliser sa boite mail, gérer ses contact …
3.2.1.2 Grands choix techniques:
Afin de maîtriser les risques, nous allons utiliser une approche itérative et incrémentale,
fondée sur le processus en Y.
Dans le cadre de son orientation vers les projets de recherche, CNI a choisit BIZTALK pour
réaliser notre projet. Ce serveur d’intégration répond parfaitement à nos besoins.
D’autre part, nous avons opté pour les choix techniques clés suivants pour notre projet :
-la modélisation objet avec UML.
- les architectures 3-tiers avec SGBDR.
- la plate-forme .NET (avec C#, ASP.NET) et les potentialités de XML pour l’échange de
flow entre les applications, la base de donnée et un ESB.
-une base de données SQL server 2005.
Page 38
La figure suivante montre la disposition de notre environnement matériel et logiciel :
Figure 10 : L’interaction entre Biztalk et les différents composants
3.2.1.3 Recueil des besoins fonctionnels:
Après une phase de recherche et consultation de représentant de CNI, nous avons pu dégager
ce cahier de charges préliminaire.
Utilisateur : il a plusieurs tâches à faire :
-Tout d’abord il doit s’authentifier pour accéder à son bureau virtuel
- Il peut accéder à ses outils bureautiques tels qu’Excel, Word, power point, calculatrice …
- Il peut gérer son propre calendrier : il peut créer un nouvel événement, fixer une réunion
qui peut être obligatoire pour quelques uns et optionnelle pour d’autres… donc l’utilisateur
peut inviter ses subordonnés, créer une tâche à faire qu’il peut accorder à ses subordonnés.
D’autre part, il peut détruire les anciens événements situés dans une plage de temps.
L’utilisateur peut voir le contenu d’autres calendriers en demandant le droit d’accès de ses
Page 39
collègues, et peut aussi superposer 2 calendriers pour pouvoir identifier le temps libre partagé
entre les 2 employés.
-Il peut gérer ses contacts, il peut ajouter un contact, le partager avec d’autre utilisateurs, il a
la possibilité d’ajouter une liste ou il peut intégrer tout ses contacts.
-L’utilisateur a aussi accès à sa boite à lettre pour consulter ses mails, il peut envoyer un
message accompagné d’une pièce jointe, il peut organiser ses email sous des dossiers. Il est
capable d’archiver ses messages dans des fichiers textes. Il peut rechercher des anciens
messages suivant la date ou le titre, comme il peut supprimer ceux qui n’a plus besoin.
-L’employé peut organiser ses documents : après le chargement de ses documents, il a la
possibilité de les organiser dans des dossiers puis il peut les partager avec les autres
utilisateurs. Chaque employé peut agir sur les documents des autres selon les privilèges
donnés par l’administrateur, il dispose également du droit de recherche des fichiers dont il a
besoin.
-Il peut écrire ses notes et les organiser dans des dossiers.
-L’employé peut communiquer avec ses collègues à travers un forum et une messagerie
instantanée. En effet, il peut accéder à des salons dans le chat suivant les groupes et
communiquer avec les autres.
-L’utilisateur peut envoyer des SMS à un destinataire ou à plusieurs en même temps. Comme
il peut envoyer et recevoir des fax.
- L’employé doit disposer d’un disque virtuel où il peut sauvegarder ses documents. Cet
espace est propre à lui, personne ne peut accéder à ses documents sans son autorisation.
-L’utilisateur peut participer à des activités extra professionnelles.
-Finalement, l’employé peut accéder à ses outils de travail suivant son département (Les
logiciels dont il a besoin suivant sa spécialité).
Administrateur : il gère les profils des utilisateurs, affecte les privilèges suivant les postes
des employés, donne les modules dont a besoin chaque utilisateur. Il gère aussi les groupes
suivant les départements.
Page 40
3.2.1.4 Identification des acteurs :
Un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur, dispositif
matériel ou autre système) qui interagissent directement avec le système étudié.
Dans notre cas on identifie l’utilisateur humain qui peut être un employé ou l’administrateur.
Employé : peut consulter son bureau virtuel, gérer ses outils, communiquer avec ses
collègues, accéder à sa boite mail, son calendrier, son disque virtuel, partager ses documents.
Administrateur : gérer les profils des utilisateurs, les groupes et les privilèges.
3.2.1.5 Identification des messages :
Un message représente la spécification d'une communication unidirectionnelle entre objets
qui transporte de l'information avec l'intention de déclencher une activité chez le récepteur.
Nous représentons dans le diagramme de contexte ci-après l’interaction entre les acteurs et le
système mettant en évidence les messages échangés.
Remarque : Etant donné que l’employé peut faire beaucoup de tâches, nous allons créer
plusieurs instances d’utilisateurs pour mettre en évidence les différentes interactions avec le
système.
Figure 11 : Diagramme de contexte dynamique 1/2
Bureau virtuel
envoye un message
dans le chat
envoie mail
l iste des contacts
ajoute un contactappel de l 'application
appel d'outils
écrire message
dans le forum
créer événement/réunion
/tâche dans son calendrier
sauvegarder
dans le
disque virtuel,
affectation
des privilèges.
document
chargement
, téléchargement
employé:employé1
employé:employé2
employé:employé3
employé:employé4 employé:employé5
employé:employé6
employé:employé7
employé:employé8
employé:employé9
Page 41
Figure 12 : Diagramme de contexte dynamique 2/2
L’étude préliminaire a pour but de collecter les besoins fonctionnels et techniques initiaux,
d’identifier les acteurs, les messages et de mettre en évidence l’interaction des acteurs avec le
système comme étant une boite noire.
3.3 Branche fonctionnelle
3.3.1 Capture des besoins fonctionnels
Cette phase représente un point de vue « fonctionnel » de l’architecture système. Par le biais
des cas d’utilisation, nous serons en contact permanent avec les acteurs du système en
vue de définir les limites de celui-ci, et ainsi éviter de trop s’éloigner des besoins réels
de l’utilisateur final.
Bureau virtuel
envoye document
par le fax confirmation
date d’une activité
gérer les modules
aquittement
envoye SMS
liste des util isateurs
ajouter, modifier,
supprimer util isateur
listes des groupes ajouter, supprimer,
modifier groupe
employé:employé10
employé:employé11
employé:employé12
admin:admin1
admin:admin2
admin:admin3
Page 42
3.3.1.1 Identification des acteurs :
Un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur, dispositif
matériel ou autre système) qui interagissent directement avec le système étudié. Dans notre
cas, l’utilisateur humain est identifié comme étant soit un employé ou l’administrateur.
Employé : peut consulter son bureau virtuel, gérer ses outils, communiquer avec ses
collègues, accéder à sa boite mail, son calendrier, son disque virtuel, partager ses documents.
Administrateur : gérer les profils des utilisateurs, les groupes et les privilèges.
3.3.1.2 Identification des cas d’utilisations
a. Liste préliminaire des cas d’utilisations
L’identification des cas d’utilisation une première fois, nous donne un aperçu des
fonctionnalités futures que doit implémenter le système. Pour constituer les cas d’utilisation,
il faut considérer l'intention fonctionnelle de l'acteur par rapport au système dans le
cadre de l'émission ou de la réception de chaque message. En regroupant les intentions
fonctionnelles en unités cohérentes, on obtient les cas d'utilisations.
Cas d’utilisation Acteur principal, acteurs
secondaires
Message(s) émis/reçus par les
acteurs
Utiliser une application Utilisateur émet : nom de l’application
Utiliser les outils Utilisateur émet : nom de l’outil
Gérer le calendrier Utilisateur émet : créer
événement/réunion/tâche
Gérer les contacts Utilisateur émet : ajoute un contact
reçoit : liste des contacts
Gérer les documents Utilisateur émet : chargement,
téléchargement
reçoit : document
Gérer la boîte mail Utilisateur émet : envoie mail
Utiliser le forum Utilisateur émet : écrit message
Gérer le disque virtuel Utilisateur Emet : sauvegarder, affectation
des privilèges.
Echanger messages avec Utilisateur émet : le message lui-même
Page 43
membres
Envoyer des SMS Utilisateur émet : message
reçoit : acquittement
Envoyer des fax Utilisateur émet : document
Participer aux activités extra-
professionnelles
Utilisateur émet : date d’une activité
reçoit : confirmation(s)
Utiliser la calculatrice Utilisateur émet : des opérations
reçoit : résultat(s)
Gérer les modules administrateur émet : nom du module
Gérer les groupes administrateur émet : ajouter, supprimer,
modifier groupe.
reçoit : listes des groupes
Gérer les utilisateurs administrateur émet : ajouter, modifier,
supprimer utilisateur.
reçoit :liste des utilisateurs
Description des cas d’utilisations
Figure 13: Diagramme de cas d’utilisations de gestion de mails
<<extends>>
<<extends>>
<<include>>
<<include>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
util isateur
gérer sa boite mail
ecrire message
introduire l'adresse de destinataire
ajouter fichier jointe
envoyer mail
supprimer message
sauvegarder mail
rechercher mail
recherche par date
recherche par nom
recherche par destinataire
gérer liste de contact
ajouter liste
editer liste
supprimer liste
ajouter un contact
supprimer un contact
éditer un contact
Page 44
Description de « gérer boite mail »
Identification
Nom du cas: gérer sa boite mail
But : L’utilisateur peut gérer sa boite mail, il peut envoyer des mails accompagnés de pièces jointes. Il
peut agir sur ses messages en les supprimant, les sauvegardant. Il peut chercher des anciens mails. Il a le
droit d’ajouter des dossiers pour organiser ses mails et il peut gérer sa liste de contacts.
Acteurs : L’employé qui consulte sa boite mail.
Pré conditions : -l’utilisateur doit être authentifié.
-l’utilisateur doit avoir son compte mail.
Post-conditions : selon l’action faite par l’utilisateur, s’il a envoyé un mail on aura un mail envoyé.
Figure 14 : Diagramme de cas d’utilisation de gestion de calendrier
Ajouter tâche
utlisateur
Gérer tâche
Gérer réunion
évennement
supprimer évenement
ajouter évennement
modifier évennement
Ajouter tâche
Supprimer tâche
Modifier tâche
Ajouter réunion
Supprimer réunion
Modifier réunin
Page 45
Description de «gérer le calendrier »
Identification
Nom du cas: gérer le calendrier
But : L’utilisateur peut gérer son calendrier en ajoutant, supprimant ou modifiant soit les événements, soit
les tâches ou les réunions.
Acteurs : L’utilisateur qui veut consulter ou modifier son calendrier
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : -un événement, une tâche ou une réunion est crée, modifié ou supprimé.
Figure 15 : Diagramme de cas d’utilisation d’envoie d’un fax
<<extends>>
Utilisateur
Envoyer un fax
envoyer à un destinataire
envoyer à plusieurs destinataires
envoyer une pièce jointe
Page 46
Description de envoyer un fax
Identification
Nom du cas: envoyer un fax
But : L’utilisateur peut envoyer un fax à un destinataire ou à plusieurs. Ce fax peut être accompagné d’ une
pièce jointe.
Acteurs : L’employé qui veut envoyer un fax.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : un fax envoyé.
Figure 16 : Diagramme de cas d’utilisation de gestion des contacts
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
gérer liste de contact
ajouter un contact
créer liste de contacts
éditer liste de contacts
supprimer liste de contacts
supprimer un contact
éditer un contact
chercher un contact
chercher un contact par nomchercher un contact par liste
chercher un contact par societe
importer contacts
exporter contacts
utilisateur
Page 47
Description de « gérer ses contacts »
Identification
Nom du cas: gérer ses contacts.
But : L’utilisateur peut gérer sa liste de contact en ajoutant des listes où il peut organiser ses contacts, il
peut également modifier ces listes ou les supprimer. D’autre part il peut ajouter des contacts, les modifier ,
les supprimer, les exporter, les importer ou rechercher un contact selon des critères .
Acteurs : L’employé qui veut gérer sa liste de contact.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : -un contact est crée, modifié ou supprimé.
b- une liste de contact est crée modifiée ou supprimée
Figure 17 : Diagramme de cas d’utilisation d’envoie d’un SMS
<<includes>>
<<includes>>
<<include>>
<<include>>
<<include>>
envoyer SMS
envoyer SMS à une personne
envoyer SMS à plusieurs
introduire num destinataire
introduire message
choisir les numero des destinataires
gérer les contacts
Utilisateur
Page 48
Description de « envoyer un SMS »
Identification
Nom du cas: envoyer un SMS
But : L’utilisateur peut envoyer un SMS à un destinataire ou à plusieurs.
Acteurs : L’employé qui veut envoyer un SMS.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : un SMS envoyé.
Figure 18 : Diagramme de cas d’utilisation de gestion du disque virtuel
<<include>>
<<include>>
<<extends>>
<<extends>>
<<extends>><<extends>>
<<extends>>
<<extends>>
gérer son disque virtuel
creer Dossier Web
copier un document
renomer un documentsupprimer un document
déplacer un document
creer un document
l'authentificationpartager un document
utilisateur
Page 49
Description de « gérer disque virtuel »
Identification
Nom du cas: gérer son disque virtuel
But : L’utilisateur peut créer son propre disque virtuel à travers la création de Dossier Web. Ensuite il peut
organiser ses documents, les créer, les sauvegarder, les déplacer, les modifier, les partager avec d’autres
utilisateurs, les supprimer.
Acteurs : L’employé qui veut utiliser un disque virtuel où il peut sauvegarder ses documents.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : Selon l’action d’utilisateur on peut avoir un document sauvegardé, supprimé, modifié ou
partagé.
Figure 19 : Diagramme de cas d’utilisation de gestion de notes
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
Gérer notesmodifier une note
organiser les notes
déplacer les notes
supprimer une note
créer une note
utilisateur
Page 50
Description de « gérer les notes »
Identification
Nom du cas: gérer les notes
But : L’utilisateur peut créer des notes où il peut introduire des remarques, des memoriums. Il peut
modifier des notes, les déplacer, les supprimer, les organiser dans des dossiers.
Acteurs : L’employé qui veut écrire ses notes.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : Selon l’action d’utilisateur on peut avoir une note modifiée, supprimée, crée, déplacée
dans un dossier.
Figure 20 : Diagramme de cas d’utilisation de gestion des applications
<<extends>>
Utilisateur
Administrateur
Util iser application
Gérer les applications
ajouter application(s)
supprimer application(s)
donner privilèges
Page 51
Description de « gérer les applications »
Identification
Nom du cas: gérer les applications.
But : L’utilisateur peut utiliser les applications qui lui ont été assignées par l’administrateur. Ce dernier ne
peut pas voir celles dont il n’a pas le privilège. Quant à l’administrateur, il a la possibilité de gérer, soit en
ajoutant, en supprimant ou en donnant les privilèges aux utilisateurs.
Acteurs : L’employé qui veut utiliser une application.
L’administrateur qui, à part la possibilité d’utiliser les applications existantes, peut administrer celles-ci.
Pré conditions : -l’utilisateur/administrateur doit être authentifié.
Post-conditions : Selon l’action on peut avoir une application ajoutée, supprimée ou tout simplement
lancée .
Figure 21 : Diagramme de cas d’utilisation de participation dans forum
<<extends>>
<<extends>>Utilisateur
Utiliser forum
Exporter sujet(s)
Participer a un sujet
Supprimer sujet
Administrateur
Page 52
Description de « utiliser forum »
Identification
Nom du cas: utiliser forum.
But : L’utilisateur peut utiliser un forum soit en y participant, soit en exportant un sujet. L’administrateur
peut quant à lui supprimer un sujet s’il juge nécessaire.
Acteurs : L’utilisateur qui veut exploiter un forum.
Pré conditions : -l’utilisateur/administrateur doit être authentifié.
Post-conditions : Selon l’action on peut modifier le contenu d’un forum en y participant, l’exporter ou le
supprimer.
Figure 22 : Diagramme de cas d’utilisation de gestion des documents
<<include>>
<<include>>
<<extends>>
<<include>>
<<extends>><<extends>>
<<extends>>
<<include>>
utlisateur
Gérer les documents
Charger un document
Télécharger un document
Chercher un document Entrer critère(s) de recherche
Spéçifier cheminSpéçifier accèssiblité
Organiser les documents
Déplacer vers un dossier Créer dossierRenommer documentDétruire document
Partager document
Envoyer par mail
Page 53
Description de « gérer les documents »
Identification
Nom du cas: gérer les documents.
But : L’utilisateur peut effectuer plusieurs opérations sur les documents : chargement, téléchargement,
recherche, organisation et partage.
Acteurs : L’employé qui veut gérer ses documents.
Pré conditions : -l’utilisateur/administrateur doit être authentifié.
Post-conditions : Selon l’action on peut avoir un nouveau document ou agir sur un document existant.
Figure 23 : Diagramme de cas d’utilisation de consultation d’actualités
<<include>>
Utilisateur
Consulter actualités
Actualités intra entreprise
Actualités extra entreprise Définir le(s) domaine(s)
Page 54
Description de « consulter actualités »
Identification
Nom du cas: consulter actualités.
But : Les utilisateurs ont la possibilité de consulter les actualités de leur entreprise ainsi que celles du
monde. Chaque utilisateur pourra choisir les domaines ou les sites qui l’intéressent et cette fonction lui
apportera les nouveautés si elles existent. L’administrateur quant à lui aura le privilège de gérer les
actualités de l’entreprise.
Acteurs : L’employé qui veut être en alerte des actualités.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : Selon l’action on peut voir les actualités intra ou extra entreprise.
Figure 24 : Diagramme de cas d’utilisation de discuter avec la messagerie instantanée
<<include>>
<<include>>
Utilisateur
Discuter
Définir le pseudo
Spéçifier le canal
Administrateur
Gérer les canaux
Supprimer un canal
Ajouter un canal
Modifier un canal
Page 55
Description de « Discuter avec un collègue »
Identification
Nom du cas: Discuter avec un collègue.
But : Les utilisateurs du bureau virtuel peuvent s’échanger des messages dans le cadre de leur entreprise à
travers des canaux de discussion créée par l’administrateur. L’administrateur a bien évidement des
privilèges comme la création, la suppression ou la modification des caractéristiques du canal.
Acteurs : L’employé qui contacter un collègue sans se déplacer.
L’administrateur pour gérer les canaux.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : Selon l’action on peut soit entrer en communication avec un collègue soit influer sur la
gestion des canaux.
Figure 25 : Diagramme de cas d’utilisation de gestion des tâches
Utilisateur
ajouter une tache
supprimer une tache
modifier une tache
ajouter tache personnelle
ajouter tache assignée
Page 56
Description de « gestion des tâches »
Identification
Nom du cas: Gérer les tâches.
But : L’utilisateur peut ajouter une tâche qui peut être soit personnelle soit assignée à un autre employé qui
doit être son subordonné, comme il peut lister ses tâches, les modifier ou les supprimer.
Acteurs : L’employé qui va gérer ses tâches.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : Selon l’action on peut avoir une nouvelle tâche ou agir sur une tâche existant.
3.3.1.3 Diagramme de classes participantes
Figure 26 : Diagramme de classes participantes
1..*
1..1
0..*
0..*
1..1
0..*
0..10..*
1..1
0..*
1..1
0..*
1..*
1..1 1..1
0..*
1..*
0..*
1..*
0..*
1..*
0..*
1..* 0..*1..1
0..*
1..1
0..*
0..*
1..1
0..*
1..1
1..1
0..*
1..1
0..*
0..*
1..1
1..1
0..*
1..10..*
GestionModules
Module
Utilisateur
Groupe
GestionGroupe
GestionProfil
Profil
Calendrier
Evenement
Reunion
chat
Contacts
Contact
Liste
Documents
Document
Dossier
GestionTaches
Tache
Statut
Priorite
GestionMessagesMessage
ServeurMessagerie
GestionSms
Sms
Fax
Note
DisqueVirtuel
GestionNotes
Page 57
3.3.1.4 Exigences non fonctionnelles
a. Disponibilité :
La disponibilité du système et des données est un enjeu majeur pour les utilisateurs donc il
doit être accessible pour les utilisateurs 7/7j et 24/24h.
A cette fin, un scénario de serveur de backup peut être envisagé dans les limites des moyens
techniques disponibles.
b. Sécurité :
La sécurité fait appel à différentes techniques complémentaire afin d’assurer
l’authentification, la confidentialité et l’intégrité des informations échangées.
Au niveau de l’authentification des utilisateurs on oblige l’utilisateur à utiliser un mot de
passe complexe.
A la suite de nième
tentative échouée de connexion au compte, l’utilisateur se voit dans
l’obligation de récupérer son nouvel mot de passe par mail.
Ce dispositif est nécessaire pour éliminer le risque de générateur de mots de passe.
c. Ergonomie :
L’Interface Homme/Machine doit être avant tout intuitive .Ainsi les utilisateurs non
informaticiens pourront s’y trouver plus facilement. L’aspect esthétique est aussi à ne pas
négliger.
d. Temps de réponse :
Le système doit répondre aux requêtes des utilisateurs en un minimum de temps possible.
Cette contrainte dépondra fortement de la nature de connections et de la bande passante des
utilisateurs et de la puissance calculatoire des serveurs utilisés.
e. Intégrité :
Les données inter-changées ne doivent subir aucune altération ni destruction volontaire ou
accidentelle
Page 58
3.3.2 Analyse
3.3.2.1 Découpage en catégories
Dans un projet de grande envergure où la charge de travail devient importante, la classe sera
perçue comme une entité de structuration trop petite pour la vision globale du projet.
La répartition des tâches devient elle aussi un élément majeur à l’organisation et à la bonne
conduite du projet.
Afin de palier à ces limites, UML introduit à ses utilisateurs un diagramme qui prend en
considération ces besoins : Ce diagramme est le diagramme des paquetages. Si on entre dans
le détail, on s’apercevra que les objectifs du découpage en catégories sont multiples et très
souvent cruciaux pour la réussite du projet. Parmi ces objectifs, on peut citer :
Organiser les équipes pour travailler sur des ensembles cohérents (la cohérence
implique le regroupement par compétence métier) et faiblement couplés (pour pouvoir
travailler parallèlement sur différents modules).
Diminuer la complexité par l’organisation. La décomposition servira donc à faire
ressortir la collaboration d’ensemble (au niveau d’un modèle structurel).
Assurer l’évolutivité et la facilité de maintenance en favorisant la réutilisation. On
séparera donc les parties applicatives (qui varient a chaque projet et sont sujette aux
changements), des parties métiers (généralement plus stables et meilleures candidates
aux changements).
Une première répartition des classes candidates (découvertes précédemment) est illustrée à la
figure suivante :
Page 59
Figure 27 : Le découpage en paquetages
Voici les raisons de ce découpage :
Les catégories « utilisateurs et groupes », « gérer contacts » et « gérer profil »
ont été séparées selon les critères de réutilisabilité, puisqu’ils correspondent à
des services classiques dans toute application informatique mais pas à un
service métier.
Les catégories « gérer calendrier », « chat », « « gestion sms », « gestion
fax », « gestion documents », « gestion disque virtuel », « gestion message » et
« gestion disque virtuel » sont relativement « maigres », cependant nous avons
décidé de les séparer car elles sont faiblement liées.
3.3.2.2 Développement de modèle statique
Le développement du modèle statique constitue la deuxième étape de l’analyse.
Les diagrammes de classes établis sommairement dans les diagrammes de classes
participantes, puis réorganisés lors du découpage en catégories, vont être complétés et
optimisés.
<<category>>
util isateur et groupe
+
+
+
+
Profil
Groupe
Util isateur
Module
:
:
:
:
<<category>>
gestion des groupes et des profils
+
+
+
GestionProfil
GestionGroupe
Gestion Module
:
:
:
<<category>>
Gestion Disque Virtuel
+ Disque Virtuel :
<<category>>
Gestion Fax
+ Fax :
<<category>>
Gestion Messages
+
+
+
GestionMessages
Message
ServeurMessagerie
:
:
:
<<category>>
Gérer Documents
+
+
+
Documents
Document
Dossier
:
:
:
<<category>>
Gérer Contacts
+
+
+
Contacts
Contact
Liste
:
:
:
<<category>>
Gérer Calendrier
+
+
+
+
+
+
Calendrier
Tache
Evenement
Reunion
Priorite
Statut
:
:
:
:
:
:
<<category>>
Chat
+ Chat :
<<category>>
Gestion Sms
+
+
GestionSms
Sms
:
:
<<category>>
Gestion Notes
+
+
GestionNotes
Note
:
:
Page 60
Il s’agit d’une activité itérative, fortement couplée avec la modélisation dynamique.
Dans cette partie, nous serons amenés à affiner, compléter et optimiser notre modèle de
classes participantes vue dans la phase de captures des besoins fonctionnels et réorganisés lors
du « découpage en catégories ».
Nous allons nous intéresser plus particulièrement aux catégories que nous allons être amenés
à réaliser et non toutes.
Catégorie « utilisateurs et groupes » :
Voici le diagramme de classe de la catégorie « utilisateurs et groupes »
Figure 28 : diagramme de classe des utilisateurs et groupes
Catégorie « gestion des groupes et des profils » :
Voici le diagramme de classe de la catégorie « gestion des groupes et des profils »
1..1
0..*
Utilisateur
-
-
idUtilisateur
privilege
: int
: bool
Groupe
-
-
idGroupe
nomGroupe
: int
: String
Profil
-
-
-
-
-
-
-
-
-
-
-
idProfil
nom
prenom
telephone
adresse
dateDeNaissance
login
mp
numGSM
numFax
: int
: String
: String
: long
: String
: String
: Date
: String
: String
: int
: int
Page 61
Catégorie « gestion des messages » :
0..1
0..*
1..1
0..*
1..10..*
1..*
1..1
1..1
0..*
Utilisateur
-
-
idUtilisateur
privilege
: int
: bool
Groupe
-
-
idGroupe
nomGroupe
: int
: String
GestionGroupe
+
+
+
AjoutGroupe (Groupe g)
ListGroupe ()
SupprimerGroupe (Groupe g)
: int
: ArrayList[]
: bool
GestionProfil
- ListProfils : ArrayList[]
+
+
+
+
AjouteProfil (Profil p)
SupprimeProfil (Profil p)
ListeProfils ()
ModifierProfil (Profil p)
: int
: bool
: ArrayList
: Profil
Profil
-
-
-
-
-
-
-
-
-
-
-
idProfil
nom
prenom
telephone
adresse
dateDeNaissance
login
mp
numGSM
numFax
: int
: String
: String
: long
: String
: String
: Date
: String
: String
: int
: int
1..1
0..*
0..*
1..1
GestionMessages
+
+
+
envoyerMessage ()
supprimerMessage (int idMessage)
archiverMessages (Message[] listMsg)
: int
: int
: int
Message
--
-
-
-
idMessageexpediteur
destinataire
sujet
texte
: int: string
: string
: string
: string
ServeurMessagerie
--
idServeurnom
: int: string
+
+
+
migrationServeur (int idDestServer)
run ()
stop ()
: bool
: void
: void
Page 62
Catégorie « gestion des tâches » :
Voici le diagramme de classe de la catégorie « gestion des taches »
3.3.2.3 Développement de modèle dynamique
Le développement du modèle dynamique constitue la troisième étape de la phase d’analyse.
C’est une activité itérative fortement couplée avec le développement du modèle statique.
Cependant, il faut mentionner que tous les scénarios possibles ne peuvent être mentionnés ici.
C’est pour cette raison que nous allons faire une description des scénarios les plus pertinents.
Digramme d’activité de « envoi mail »
0..*
1..1
0..*
1..1
1..1
0..*GestionTaches
+
+
ajouterTache (Tache t)
supprimerTache (int idTache)
: int
: int
Tache
-
-
-
-
-
idTache
sujet
description
dateDebut
dateFin
: int
: int
: int
: DateTime
: DateTime
Statut
-
-
idStatut
nom
: int
: string
Priorite
-
-
idPriorite
nom
: int
: int
Page 63
Diagramme d’activité de « envoie SMS »
Consulter calendrier collègue
Page 64
3.4 Branche technique
3.4.1 Capture des besoins techniques
La capture des besoins techniques couvre les spécifications logicielles et la structure
matériel. Cette branche est primordiale dans le cycle de vie Y (2TUP dans notre cas), elle
donne une vision globale sur l’architecture générale de notre projet. Cette étape comporte 2
grandes lignes : les spécifications techniques et les spécifications logicielles
Figure 29 : Situation de la capture des besoins techniques dans 2TUP
3.4.1.1 Spécifications techniques du point de vue matériel
a. Grands choix techniques
Après une étude réalisée sur notre projet et en vue de satisfaire nos besoins fonctionnels nous
avons fait des choix techniques qui peuvent remédier à quelques problèmes rencontrés lors de
l’étude préliminaire.
Ces choix techniques sont les suivants :
Page 65
-la modélisation objet avec UML.
- les architectures 3-tiers avec SGBDR.
- le déploiement en client riche.
- la plate-forme .NET (avec C#, ASP.NET) et les potentialités de XML pour l’échange de
flow entre les applications, la base de donnée et un ESB.
-une base de données SQL server 2005.
-un EAI (BizTalk) pour connecter les différents serveurs, la base de données et les différentes
applications.
Figure 30 : L’interaction d’un EAI avec les différentes applications, serveurs et bases de données
b. Style d’architecture en niveaux
L’architecture à trois niveaux met en œuvre le système informatique d’une entreprise. Nous y
trouvons les niveaux suivants : central, départemental et local. Une telle architecture couvre
les différents métiers de l’entreprise. L’étude de cas CNI en constitue un exemple.
Page 66
3.4.1.2 Spécification logicielle :
Dans cette partie, nous allons introduire les cas d’utilisation de manière différente de celle de
capture des besoins fonctionnels. A cette fin, nous définissons 2 concepts : Celui d’exploitant
et celui de cas d’utilisation technique.
-L’exploitant est un acteur qui bénéficie des fonctionnalités techniques du système. Il s’agit
de l’utilisateur dans son sens le plus général, dans notre cadre on peut considérer chaque
employé indépendamment de son rôle comme un exploitant.
- Un cas d’utilisation technique est destiné à l’exploitant. C’est une séquence d’actions
produisant une valeur ajoutée opérationnelle ou purement technique. Il recouvre en effet tous
les services techniques dont un utilisateur bénéficie.
Nous allons ainsi entamer la réalisation d’un modèle de spécification logicielle qui est
composé de 2 itérations : la 1ere définit les besoins techniques des exploitants à travers des
cas d’utilisation techniques, la 2eme subdivise le modèle de spécification en couches de
responsabilités techniques.
a. Identification des cas d’utilisation techniques
Les exploitants du système CNI sont :
l’utilisateur qui utilise le bureau virtuel. La majorité des acteurs de la branche
fonctionnelle sont donc des utilisateurs dans la dimension technique.
Un administrateur, qui est chargé de déployer et de dépanner le système.
Les cas d’utilisation techniques de CNI sont d’abord identifiés en considérant l’attente
opérationnelle de chaque exploitant :
- L’utilisateur va travailler avec des entités sous la forme d’objets, ce qui implique la mise en
œuvre des mécanismes de persistance et de gestion de cycle de vie des objets.
-Plusieurs utilisateurs peuvent travailler en parallèle. L’intégrité est le mécanisme qui
empêche la mise à jour simultanée d’une même entité par deux utilisateurs différents.
- chaque utilisateur utilise les différents modules de bureau virtuel qui nécessite le passage par
l’ESB et la communication entre la couche métier, le serveur adéquat et la base de données.
Page 67
Ainsi, les temps de réponse du système ne s’en trouvent pas dégradés en fonction du nombre
d’utilisateurs connectés.
-l’utilisateur doit se connecter et être reconnu du système pour pouvoir y travailler.
L’authentification est le mécanisme qui protège le système des intrusions externes.
- chaque utilisateur doit disposer d’une aide contextuelle pour exploiter le bureau virtuel de la
manière la plus efficace.
-Le bureau virtuel doit être exploitable afin de générer des traces qui facilitent sa
maintenance.
- l’administrateur ainsi que l’utilisateur sont soumis à des règles de sécurité
(l’authentification, le cryptage, la non répudiation et l’audit).
Figure 31 : Diagramme de cas d’utilisations techniques
Page 68
b. Définition initiale des cas d’utilisation technique
Cas d’utilisation : manipuler des objets :
Intention : l’utilisateur désire agir sur le cycle de vie d’un ou plusieurs
objets.
Actions : créer, modifier, supprimer un objet.
Identification du besoin : gestion des modules de bureau virtuel.
Exemple : L’utilisateur gère son calendrier il peut créer un événement ou
une réunion, inviter les autres employés, modifier ou supprimer
ces derniers.
Cas d’utilisation : Gérer l’intégrité:
Intention : 2 utilisateurs ne doivent pas agir sur la même entité
simultanément.
Actions : Lors de la modification d’un objet la table doit être protégée en
écriture d’une autre intervention.
Identification du besoin : Gestion de l’intégrité.
Exemple : Un chef de département fixe la date d’une réunion et invite ses
employés, leurs calendriers changent automatiquement donc
l’intervention de l’employé sur son propre calendrier ne peut
pas affecter la même date au même moment.
Cas d’utilisation : Consulter l’aide:
Intention : L’utilisateur peut consulter l’aide pour connaitre le
fonctionnement du bureau virtuel.
Actions : Accéder a l’aide dans le menu.
Identification du besoin : L’utilisation de l’aide.
Exemple : Un utilisateur a du mal à utiliser sa boite mail donc il peut
consulter l’aide.
Page 69
Cas d’utilisation : Gérer les erreurs:
Intention : L’administrateur peut visualiser les alertes et les fichiers log
pour faciliter la maintenance de système.
Actions : Consulter le fichier journal.
Identification du besoin : Gestion des erreurs.
Exemple : L’administrateur peut identifier la cause d’un bug de système
grâce aux traces.
Cas d’utilisation : Gérer la sécurité:
Intention : L’administrateur et l’utilisateur sont soumis à des règles de
sécurité.
Actions : S’authentifier et échange des flux cryptés.
Identification du besoin : Gestion la sécurité.
Exemple : L’utilisateur doit s’authentifier pour protéger le système des
intrus.
3.4.2 Conception générique
La conception générique consiste à développer la solution qui répond aux spécifications
techniques. Cette conception est totalement indépendante de l’aspect fonctionnel, elle définit
les composants sous forme de classes et des frameworks techniques réutilisables nécessaires à
la construction de l’architecture technique. Elle a pour objectif d’uniformiser et de réutiliser
les mêmes mécanismes pour tout un système.
L’architecture technique construit le squelette du système informatique et écarte la plupart des
risques de niveau technique. L’importance de sa réussite est telle qu’il est conseillé de réaliser
un prototype pour assurer sa validité. Cette phase de prototypage est fortement conseillée, car
la qualité d’une conception générique conditionne généralement celle du développement pour
le reste du projet.
Dans une conception générique, le concept d’intégrité se manifeste par un ensemble de
classes dites techniques que l’on réutilise pour développer les différentes composantes
Page 70
fonctionnelles du système. Cependant, une classe technique n’ayant rarement d’effet toute
seule, c’est pour cela que l’on y associe le concept-clé de la conception générique : le
framework technique.
3.4.2.1 Classes et frameworks techniques
Un Framework technique est un ensemble de librairies ou de classes techniques permettant de
réaliser un ensemble de fonctionnalités n’ayant pas attrait à un métier particulier. Un
framework peut être abstrait ou concret.
Dans le premier cas, il est constitué d’interfaces et la réutilisation de framework consiste à les
implémenter. Il peut être aussi composé de classes qu’on peut les réutiliser.
Dans le deuxième, il détermine de plus le modèle d’exploitation.
Dans notre projet, nous nous intéressons à quatre frameworks techniques :
Framework de journalisation.
Framework de sécurité.
Framework d’authentification.
Framework EAI.
3.4.2.2 Framework de journalisation
C’est le framework qui va assurer l’audit des opérations effectuées sur les postes clients et
serveurs. Dans notre application nous essaierons de répondre à certaines contraintes telles que
les logs de démarrage et d’arrêt de l’application, la journalisation d’ajout d’un nouveau
utilisateur et l’envoi d’un mail personnalisé à l’administrateur lorsque l’utilisateur effectue
une opération spécifique.
En effet, le framework .NET fournit plusieurs classes qu’on peut réutiliser, redéfinir ou hériter
pour pouvoir assurer la journalisation de notre application. Pour la journalisation de
l’événement « création d’un nouvel utilisateur » nous créeons un fournisseur étendu qui
hérite de classe SqlMemberShipProvider responsable de la gestion de la sauvegarde des
données utilisateurs dans notre base de données Microsoft SQL server standard. Nous
pouvons également utiliser les classes situées dans le namespace System.Diagnostics qui gère
la journalisation.
Page 71
D’autre part nous allons journaliser les événements liés à la durée de vie de l’application
(démarrage/arrêt). A cet effet, nous ajouterons une section <health monitoring> au ficher
web.config de notre application. Cette dernière peut contenir plusieurs balises qui gère tout
l’aspect de traçabilité de notre site. Dans un premier lieu nous ajoutons la balise <Rules> qui
fixe les règles de d’audit dans cette section puis la journalisation de démarrage de
l’application.
En dernier lieu nous procéderons à l’automatisation de la tâche d’envoi du mail de
notification d’un événement à l’administrateur. Pour ce faire, nous créeons une classe
technique qui hérite de la classe WebBaseEvent tout en ajoutant le namespace
System.Web.Management qui contient les classes de gestion des événements, puis nous
définissons le constructeur qui sera sous ce format
NomDeClasse (string message, object eventSource, int eventCode, string parametre)
Ce dernier paramètre est personnalisé et notre application l’envoie lors de l’exécution de
l’événement. Ensuite nous redéfinissons la méthode FormatCustomEventDetails pour
construire le message personnalisé qui va être envoyé dans un mail à l’administrateur pour la
notification. Puis nous instancions notre classe où sera déclenché l’événement. Enfin nous
ajoutons une sous section dans la balise <heath monitoring> qui s’intitule <providers> où on
nous avons définis les paramètres d’envoi du mail.
3.4.2.3 Framework de sécurité
Ce framework technique semble être nécessaire de nos jours surtout pour les données
confidentielles. Ceci nous a poussé à penser au chiffrement de notre chaine de connexion aux
bases de données qui contient le chemin de la base, le login et le mot de passe qu’on peut pas
les laisser en clair donc on peut donner la main à l’administrateur pour crypter la chaine dès
qu’il veut. Pour réaliser cette tâche, nous avons recours à deux namespaces
System.Web.Configuration et System.Web.Security. La section de chaine de connexion
est ensuite choisie dans le web.config puis deux méthodes l’une chiffre l’autre déchiffre sont
implémentées.
Page 72
3.4.2.4 Framework d’authentification
Le framework .NET fournit des fournisseurs standards prêts à l’utilisation comme le cas de
l’authentification. En fait, le fournisseur MemberShipProvider gère tout les aspects propres
aux utilisateurs comme l’ajout, la modification, la suppression et même la gestion des profils
des utilisateurs. Donc il nous reste qu’à utiliser les contrôles définis dans ASP.NET Login et
CreateUserWizard.
3.4.2.5 Framework d’EAI
Dans notre cas, nous allons utiliser Biztalk server 2006 R2 d’une part pour assurer la
connectivité entre les différents applications, serveurs et bases de données d’autre part pour
garantir les transformations des données échangées entre eux et aussi pour introduire des
règles métiers sur le flux envoyé d’une application à une autre.
Ainsi, il nous semble nécessaire de donner un aperçu sur le fonctionnement de Biztalk server,
La combinaison de différents systèmes dans des processus métiers pertinents est un problème
provocant. En conséquence, le serveur 2006 de BizTalk inclut une diversité de technologies.
La figure ci-dessous illustre les composants principaux du produit :
Figure 32 : Les composants de Biztalk server 2006 R2
Comme la figure le suggère, le cœur du produit est le moteur du serveur 2006 de BizTalk. Le
moteur a deux parts principales:
Page 73
Un composant d’échange de messages qui fournit la capacité de communiquer avec
d’autre application en se basant sur des adaptateurs pour différents genres de
transmission, le moteur peut supporter une variété de protocoles et de formats de
données, y compris les services web et beaucoup d'autres.
Le soutien de créer et d'exécuter des processus graphiques a appelé des orchestrations.
Construit sur les composants de la transmission de messages du moteur, les
orchestrations mettent en application la logique qui agit sur l'ensemble ou une partie
d'un processus métier.
Plusieurs autres composants peuvent également être utilisés de concert avec le moteur,
incluant:
Un Business Rule Engine qui évalue les ensembles de règles complexes.
Une Health and Activity Tracking tool qui laisse les administrateurs surveiller et
contrôler le fonctionnement du moteur et les orchestrations.
Un Enterprise Single Sign-On (SSO) qui fournit la capacité de tracer l'information
d'authentification entre Windows et les autres systèmes d’exploitation.
Sur cette base, le serveur 2006 de BizTalk inclut un groupe de technologies qui satisfont les
besoins plus commerciaux des ouvriers de l'information. Ces technologies sont:
Business Activity Monitoring(BAM), que les ouvriers de l'information utilisent pour
surveiller un processus métier courant. L'information est affichée en métier plutôt que
termes techniques, et les utilisateurs métier déterminent quelle information est
affichée.
Business Activity Services, que les ouvriers de l'information utilisent pour installer et
pour contrôler des interactions avec les partenaires commerciaux.
Page 74
Figure 33 : L’architecture de Biztalk server
Les données sont reçues par un Receive Port. Les receive ports ne font que transmettre les
données en format binaire, sans se soucier du contenu de ce qu’ils transportent. Elles sont
acheminées vers une base de données centrale par une Receive Pipeline. C’est lors de cette
phase du transport que le mapping sera appliqué aux données binaires pour fournir un format
XML comprenant des promoted properties. Ensuite, si des orchestrations sont configurées
pour agir sur le type de message reçu, elles seront instanciées. Une orchestration est une étape
du processus métier qui est prise en charge par BizTalk. Les Send Pipelines sont l’exact
opposé des Receive Pipelines. Ces pipelines vont prendre les données sous format XML et les
convertir dans le format destination désiré. Encore une fois grâce à un mapping. Les données
sont enfin envoyées au destinataire par un Send Port qui ne se charge que de transmettre les
informations binaires au bon endroit.
Pour savoir quelle est l’étape à appliquer à un message à un moment donné, BizTalk garde un
fichier supplémentaire, le fichier de contexte.
Ce fichier de contexte possède de nombreuses information tel que :
Le type du fichier message.
L’historique complet du fichier à travers le processus BizTalk.
Page 75
Les erreurs éventuelles survenues.
Les différentes promoted properties.
La MessageBox , cœur de BizTalk, repose sous SQL-Server ce qui nous offre beaucoup de
possibilités quant à la fragmentation de cette base de données.
Lorsque qu’un fichier est reçu par BizTalk on parle de message. Les messages peuvent-être
dupliqués. Ainsi si plusieurs artefacts ont une suscription qui correspond à un même message,
chacun de ces artefacts recevra une copie autonome du message.
Maintenant que nous avons une vue globale de l’architecture de BizTalk, nous allons pouvoir
nous intéresser en détail à chaque artéfact :
a. Port
Un port est la représentation logique d’une communication physique par laquelle BizTalk
reçoit et envoie des messages.
Chaque port est un conteneur qui possède toutes les informations nécessaires à l’établissement
d’un canal de communication.
L’élément principal d’un port est l’adaptateur qu’il utilise. Chaque type de communication
possède son adaptateur.
Par exemple, un Send Port utilisant le protocole FTP possèdera un adaptateur FTP ainsi que
les configurations suivantes :
IP de contact
Login
Password
Pour ne citer que les plus évidentes.
Page 76
Receive Port
Les receive ports ont pour particularité d’être des conteneurs de Port. Ainsi un unique receive
port peut en fait être associé à plusieurs configurations différentes, nommées Receive
Location.
Ainsi un receive port attendant des ordres d’achat pourra être composé de plusieurs receive
locations :
La première attendant des fichiers sur un FTP
La seconde sur le système de fichier d’un serveur
La troisième par mail
Quelle que soit l’origine du fichier reçu, il sera traité de la même manière dans la suite du flux
de donnée.
Send Port
En contradiction avec les receive port, les send ports eux ne peuvent contenir qu’un unique
port de destination.
Pour palier ce désavantage, BizTalk offre la possibilité de créer des SendPortGroup,
contenant plusieurs Send Port.
Logical Port
Lors de la création d’une orchestration, le programmeur ne sait pas forcément d’où lui
viendront les données, ni où il devra les envoyer ensuite.
C’est dans ces cas précis qu’interviennent les ports logiques.
Les ports logiques ne doivent être liés à des ports physiques qu’au moment du déploiement de
l’application.
Dynamic Send Port
Ces send ports particuliers permettent de définir la destination des messages au moment de
l’exécution au lieu de le faire lors déploiement de l’application.
Cette destination doit être définie par déduction sur des promoted properties.
Page 77
b. Adaptateur
Les adaptateurs sont les interfaces de communication de BizTalk autant en entrée qu’en
sortie.
La plupart du temps, les adaptateurs ne sont que des interfaces de communication basées sur
un protocole de transport donné. Ils n’ont donc aucune compréhension interne des données
qu’ils transportent.
Leur unique utilité est de nourrir et de délester la machinerie de BizTalk.
Dans le cas d’adaptateur de réception, deux modes principaux existent :
Le pooling : de temps à autre l’adaptateur vérifie le contenu d’un répertoire (ou autre)
pour vérifier si des messages attendu par BizTalk ne s’y trouve pas. C’est le cas du «
File System Adaptater ».
L’écoute : l’adaptateur est en attente d’un événement en provenance su monde
extérieur pour se réveiller.
Lorsqu’un message est reçu par un adaptateur, contrairement à ce que l’on dessine
habituellement, il n’est pas envoyé directement à une receive pipeline mais passe d’abord par
la MessageBox.
C’est le « Message Engine » de BizTalk qui à la charge de transmettre ce message de la
MessageBox a la receive pipeline appropriée.
Un adaptateur des plus importants est le « SQL Adaptater ». En effet, la MessageBox
reposant sur une base de données SQL Server, chaque communication interne à BizTalk
repose sur cet adaptateur.
c. Pipeline
Les pipelines ont pour fonction d’effectuer des traitements de données sur les messages
entrants ou les messages sortants. Cet aussi cet artéfact qui à comme responsabilité la
validation de ces messages.
Par traitements de données on entend principalement tout ce qui est sécurité
(cryptage/décryptage, signature).
Page 78
BizTalk fournit 4 pipelines basiques qui permettent de remplir toutes les fonctions les plus
couramment utilisées :
Receive Pipeline
XmlReceive : permet de recevoir des messages XML et de les valide
PassThruReceive : permet de recevoir des messages sous format flat file
SendPipeline
XmdTransmit : permet d’envoyer des messages XML et de les valider
PassThruTransmit : permet d’envoyer des messages sous format flat file
Comme son nom l’indique, un pipeline est un suivi d’opérations les unes aux suites des
autres. Dans un pipeline, l’ordre des opérations est très important. En effet, a quoi bon par
exemple essayer de valider un fichier XML qui n’a pas été décrypté.
Pour simplifier la mise en place de pipeline, BizTalk à séparé en grands groupes les type
d’opérations pouvant être effectuées sur un message.
Receive Pipeline Operation Group
Figure 34 : Receive pipeline
1. Décode : cette étape sert à décoder les messages d’un format externe à un format
lisible par les autres composants. Le plus commun des cas de décode est sans nul
doute le décryptage.
Page 79
2. Désassemble : en fonction du type de message, cette étape va soit traduire le message
d’origine en un message XML, soit découper le message en plusieurs sous-messages plus
conforme à l’implémentation du flux.
3. Validation : valide un message à partir d’un schéma.
4. Résoudre les partenaires : cette étape est principalement utilisée pour certifier la
provenance des messages reçus.
Send Pipeline Operation Group
Figure 35 : Send pipeline
1. Pré-assemble : cette étape est le dernier point de modifications des données par le flux
BizTalk, généralement utilisée pour faire des transformations de dernière minute sur le
XML interne de BizTalk avant qu’il ne soit transformé en flat file.
2. Assemble : utilisation d’un schéma pour transformer un ou plusieurs messages en un
message respectant le format convenant au destinataire.
3. Encode : à l’inverse de décode, cette phase est utilisée pour crypter les données. (Un autre
exemple est la compression des données) De nombreux composants de pipelines effectuant
ce genre d’opération sont inclus dans BizTalk mais il est toujours possible d’écrire nos
propres composants ou d’en acheter de nouveau, comme d’habitude.
d. Orchestration
Les orchestrations permettent au développeur BizTalk d’implémenter un processus métier à
travers un outil de dessin : l’Orchestration Designer.
Cet outil permet d’exprimer le processus métier via une série de forme glissée sur la surface
de dessin à partir de la boîte à outil de Visual Studio.
Page 80
A travers ces dessins, tout le Framework .Net ainsi que le Framework BizTalk sont
accessibles.
Il est ainsi possible de laisser libre cours à son implémentation du processus métier sans pour
autant devoir écrire plusieurs programmes fastidieux pour gérer chaque étape de ce processus.
Les orchestrations, tout comme les autres artéfacts de BizTalk, souscrivent à certain messages
arrivant dans la MessageBox et sont instanciées par celle-ci lorsque l’un deux arrive.
Ces orchestrations sont alors capables, par exemple de gérer des exceptions telles que : « A la
réception d’un ordre d’achat j’envoie une facture, mais si je n’ai pas d’accusé de réception
avant 2 jours, j’annule l’ordre »
Encore une fois, les « shape d’orchestration », ces fameuses formes servant à dessiner sont
nombreuses mais il est toujours possible de créer les nôtre.
3.4.2.6 Les spécifications logicielles et matérielles
Avant d’achever ce chapitre nous définissons quelques serveurs et quelques plateformes que
nous allons utiliser :
Nous commençons tout d’abord par définir le Framework .NET 2.0 que nous allons utiliser
pour développer le grand morceau de code.
a. Framework .NET 2.0
Contrairement aux idées reçues .NET n’est pas un langage ou un logiciel : .NET est en fait la
nouvelle stratégie de Microsoft. .NET se présente donc comme une vision de la prochaine
génération d’applications qui repose sur des standards tels que XML, HTTP, SOAP, WSDL…
Pour donner corps à cette vision, Microsoft se repose sur quatre piliers :
Le Framework .NET
Les .NET Servers (futures versions Serveur de Microsoft).
Visual Studio .NET
.NET Enterprise servers (tous les logiciels serveurs comme Commerce Server, SQL
Server, Content Management Server…)
Page 81
Le .NET Framework est un environnement qui est distribuable gratuitement sur toutes les
versions de Windows depuis Windows 95. Les .NET Servers sont la nouvelle génération des
Serveurs Microsoft qui vont donc succéder aux Windows 2000 Servers.
Les avantages de .NET pour les entreprises sont multiples et variés : tout d’abord, la
productivité, c’est à dire le développement des applications, est plus rapide. Nous avons un
gain de productivité en .NET car tout est objet en .NET, comme nous venons de le voir.
Lorsque des composants sont développés, il est possible les réutiliser dans plusieurs
applications ce qui évite de développer les mêmes méthodes à chaque fois.
Voici les différentes couches du Framework :
Figure 36 : Le framework .NET
La CLR se place juste au dessus du Système d’exploitation et c’est la CLR qui va exécuter
les applications .NET puis gérer la gestion de mémoire et la sécurité de l’application. Dans
des langages traditionnels tels que le C ou le C++, le code était compilé dans un code natif,
c’est-à-dire un code machine qui était propre au processeur de la machine. La différence entre
ces langages et les langages .NET est qu’en .NET les langages ne sont pas compilés en
Page 82
langage machine, mais en code intermédiaire comme le montre le schéma ci-dessous. Ce n’est
qu’au moment de l’exécution de l’application que la CLR va interpréter le code
intermédiaire (MSIL) en code machine via son compilateur JIT (Just In Time) : le code sera
donc compilé à la volée.
b. Les protocoles et les serveurs mis en jeu pour la gestion de courriers
Le Mécanisme mis en jeu
Tout utilisateur possédant un compte e-mail sur un serveur possède : une adresse
électronique, un serveur SMTP et un serveur POP.
Nous prenons l’exemple suivant pour faciliter la compréhension de l’envoi d’un mail via le
protocole SMTP :
Figure 37: Mécanisme d'envoie d'un mail
1. Bob compose le message et l’envoie. Le message est envoyé sur le serveur
smtp.gmail.com.
2. Le serveur smtp.gmail.com reçoit le message, constate que le destinataire n'est pas
dans son domaine. Il cherche alors un serveur de messagerie dans le domaine yahoo.fr
et le trouve. Il envoie le message à smtp.yahoo.fr.
3. Le serveur smtp.yahoo.fr reçoit le message, constate que le destinataire est bien dans
son domaine. Il range alors le message dans la boîte aux lettres d’Isa.
Page 83
4. Un jour, Isa décide de consulter ses messages: elle envoie donc une requête à son
serveur pop.yahoo.fr.
5. Le serveur pop consulte alors la boîte aux lettres d’Isa, constate qu'il y a un message
dedans.
6. Il l'envoie alors à l'outil de messagerie d’Isa. [5]
Le protocole SMTP
C'est le protocole applicatif qui permet de transporter les messages sur l'Internet. Il sait
acheminer un message jusqu'à une boîte aux lettres, mais ne va pas plus loin.
Pour y arriver, il analyse dans un premier temps la partie de l'adresse située à droite du @,
pour trouver le domaine du destinataire. Si ce domaine le concerne, il cherche alors la boîte
aux lettres du destinataire en regardant la partie de l'adresse située à gauche du @. Si le
domaine du destinataire ne le concerne pas, il va chercher le serveur SMTP qui gère ce
domaine.
Il s'agit d'un protocole fonctionnant en mode connecté, encapsulé dans une trame TCP/IP. Le
courrier est remis directement au serveur de courrier du destinataire. Le protocole SMTP
fonctionne grâce à des commandes textuelles envoyées au serveur SMTP (par défaut sur le
port 25).
Le protocole POP3
Ce protocole est exclusivement utilisé pour le dialogue entre le client de messagerie et la boîte
aux lettres. Il ne fait pas de transport sur l'Internet, il permet juste à l'utilisateur de gérer son
courrier.
POP3 assure donc différents services :
Permettre au client d'extraire une copie complète ou partielle de chaque message
présent dans la file d'attente.
Supprimer tel ou tel message dans la file.
Remettre la file d'attente en ordre en supprimant les trous créés par la destruction des
messages.
POP3 tourne sous la forme d'un démon qui écoute par défaut sur le port 110.
Page 84
Dans la phase réalisation on va utiliser le serveur SMTP virtuel intégré dans le serveur IIS et
le serveur POP3 intégré dans le Windows server 2003.
3.5 Conclusion
La spécification des besoins fonctionnels et techniques nous a permis d’identifier les
différents intervenants de l’application, identifier le rôle de chacun, ainsi qu’identifier les
composants techniques qui interviennent dans notre projet. Pour cela, on s’est basé sur les
diagrammes des cas d’utilisations ainsi que l’étude des classes et frameworks techniques. Le
chapitre suivant sera consacré à la conception préliminaire et détaillé de l’application.
Page 85
CHAPITRE 4
CCoonncceeppttiioonn
1. Introduction
2. Conception préliminaire
3. Conception détaillée
4. Conclusion
Page 86
Chapitre.4 Conception
4.1 Introduction
Dans ce chapitre, nous allons présenter la phase de conception de notre projet. Cette phase
est constituée de deux étapes : la conception préliminaire qui représente le croisement entre
branche fonctionnel et branche technique, et la conception détaillée qui va se focaliser sur les
patrons de conceptions d’une part et quelque vues statiques et dynamique du système.
4.2 Conception préliminaire
La fusion entre la branche fonctionnelle et la branche technique s’effectue dans ce stade, c’est
l’étape la plus délicate, qui va intégrer la branche fonctionnelle qui constitue l’âme de projet
par la branche technique qui constitue le squelette de ce dernier de manière à tracer la
cartographie des composants du système à développer.
4.2.1 Vue dynamique du système
Nous avons vu dans les chapitres précédents que le système contient un nombre important de
modules ce qui nous pousse à choisir quelques uns parmi eux pour pouvoir terminer la
conception et la réalisation dans les délais vu la complexité de système. A cet effet, nous
avons choisi trois modules : La gestion des mails, la gestion des contacts et la gestion des
tâches.
Notre conception portera en premier lieu sur le module gestion de mail. Vu le nombre
important des scénarios qu’on peut envisager dans chaque module nous avons choisi des
scénarios que nous avons jugé importants dans chaque module.
En effet, on va commencer par le diagramme de séquence d’un scénario nominal de
consultation de mails :
Page 87
Figure 38 : Diagramme de séquence de consultation d’une boite de mails
Description de « consulter sa boite mail »
Identification
Nom du scénario: Consulter sa boite mail.
Description : – L’utilisateur accède à sa boite mail puis il choisit le type de message qu’il va consulter.
. – Si l’utilisateur veut consulter les messages qu’il a envoyés, l’application consulte la base de
données pour lister les messages.
–Sinon l’application consulte le serveur POP3 pour extraire les messages de ce dernier.
Acteurs : L’employé qui consulte sa boite mail.
Pré conditions : -l’utilisateur doit être authentifié.
-l’utilisateur doit avoir son compte mail et s’authentifier à son compte.
Nous passons maintenant au module de gestion de contacts. Nous avons choisi pour ce
module le scénario suivant : Ajout d’un contact.
Page 88
Figure 39 : Diagramme de séquence de l’ajout d’un contact
Description d’ « ajout d’un contact »
Identification
Nom du scénario: Ajouter un contact.
Description : – L’utilisateur remplit des champs d’un nouveau contact puis il appuie sur la touche ajouter.
. – Un fichier XML sera généré par l’application et contient les données introduites par
l’utilisateur, en même temps une notification sera envoyée à l’administrateur sous la forme d’un mail qui
indique que l’utilisateur X a ajouté le contact Y.
–Un traitement se fait au sein de Biztalk server 2006 sur les données reçues.
–Biztalk génère un fichier XML pour l’envoyer à l’application java.
Acteurs : L’employé qui gère ses contacts.
Pré conditions : -l’utilisateur doit être authentifié.
-l’utilisateur doit créer le groupe ou il va ajouter son contact.
Post-conditions : -un contact est créé, une notification est envoyée à l’administrateur.
Page 89
Finalement, nous arrivons au module gestion de tâche pour qui nous avons choisi le scénario d’ajout d’une tâche :
Figure 40 : Diagramme de séquence d’ajout d’une tâche
Description d’ « ajout d’une tâche »
Identification
Nom du scénario: Ajouter une tâche.
Description : – L’utilisateur crée une nouvelle tâche.
. – Si la tâche est personnelle une requête est envoyée à la base de données pour enregistrer la
tâche.
–Si la tâche est assignée un fichier XML sera généré et envoyé à Biztalk server.
–Un traitement se fait au sein de Biztalk server 2006 sur les données reçues.
–Un fichier XML sera généré par Biztalk et envoyé à l’application .NET pour demander la
validation de tâche de la part de l’utilisateur qui doit effectuer la tâche.
–L’utilisateur 2 donne son choix soit de valider soit de refuser la tâche et l’application .NET
génère un fichier XML et l’envoie au Biztalk server qui attend la réponse.
–un traitement s’effectue dans le Biztalk server.
–Si l’utilisateur 2 ne valide pas la tache qui a été assignée, une notification sera envoyée à
l’utilisateur 1 pour l’informer.
Page 90
–Sinon un fichier XML sera généré par le Biztalk et envoyé vers l’application java ou
l’information sera enregistrée dans une autre base de données.
Acteurs : L’employé qui gère ses tâches.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : -une tâche est créée ou une notification est envoyée.
4.2.2 Vue statique de système
Dans cette partie, nous nous attardons sur la vue statique de conception.
Nous serons amenés à concevoir dans cette partie chaque module à part tout en commençant
par le diagramme de classe préliminaire de gestion de mails.
Ce diagramme va contenir des sous-systèmes comme le serveur pop3 pour montrer
l’interaction entre les classes et ce dernier.
Figure 41 : Diagramme de classe de gestion de mails
Page 91
Ce diagramme présente les classes utilisées dans le module gestion de mails. La classe
gestion de mails étant une classe abstraite ne pouvant pas être instanciée, les classes
GestionMailReçus et GestionMailsEnvoyés héritent de cette classe et redéfinissent leurs
méthodes. La classe GestionMailsEnvoyés interagit avec la classe mail où on trouve les
différents attributs qui définissent un mail : cette classe constitue l’objet qui va être
sauvegardé dans la base de données lors de l’envoi du mail et ce même objet peut être listé de
la base lors de la consultation de mails envoyés. La classe GestionMailReçus interagit avec le
serveur POP3 et au même temps avec la base de données pour mémoriser l’état des mails
consultés.
Nous passons maintenant au module gestion de contact qui va intégrer lui aussi un système
externe (Biztalk server) :
Figure 42 : Diagramme de classe de gestion de contacts
Page 92
Ce diagramme est constitué de deux grands paquetages. Le premier est celui de l’application
.NET où figure la classe centrale GestionContactsGroupe qui présente une classe
intermédiaire avec qui la classe Utilisateur interroge quand l’utilisateur veut gérer ses
contacts ou ses groupes. La classe GestionGroupe gère l’objet groupe dont les attributs se
trouvent dans la classe Groupe. La classe GestionContacts agit sur la classe contacts qui
présente les champs d’un objet contact qui appartient à un groupe d’où l’agrégation entre la
classe contacts et le groupe. La classe GenerationXML présente le port qui lie l’application
.NET avec le serveur Biztalk, elle sert à générer les fichiers XML de l’ajout, modification ou
suppression d’un contact.
Pour ce qui concerne l’application java, la classe GestionContacts gère l’objet contact. Cette
classe appelle aussi la classe ConnexionBD pour accéder à la base de données et agir sur les
tables. Les classe DirectoryWatcher et FileListener constituent le port de l’application avec le
Biztalk qui présente des méthodes pour écouter le répertoire dans lequel il génère ses fichier
XML et la classe ParserXML pour parcourir ces derniers et extraire les données.
Finalement nous passons au module gestion des tâches :
Figure 43 : Diagramme de classe de gestion de tâches
La classe GestionTache gère l’objet Tâche : si la tâche traitée est personnelle, il le sauvegarde
dans la base de données, si la tâche est assignée il génére un fichier XML. L’utilisateur qui
assigne une tâche doit respecter la hiérarchie (ne pas assigner une tâche à son supérieur).
C’est pourquoi la classe poste joue un rôle important dans ce contexte. La classe écouteur
présente de port d’écoute de l’application qui attend les fichiers XML de validation de tâches.
Page 93
Nous avons ainsi achevé la partie conception préliminaire qui sert à fusionner les 2 branches
de 2TUP, nous attaquons maintenant la dernière phase de conception, la conception détaillée
qui assure une meilleure compréhension aux différentes parties de notre application.
4.3 Conception détaillée
La conception détaillée consiste à construire et documenter les classes et les méthodes qui
présentent l’implémentation de notre solution. Pour bien modéliser, nous avons recours au
design patterns qui présentent des bonnes pratiques dans la conception .,
4.3.1 Les Design patterns
En génie logiciel, un motif de conception (design pattern en anglais) est un concept destiné à
résoudre les problèmes récurrents suivant le paradigme objet. En français on utilise aussi les
termes modèles de conception ou patron de conception.
Les patrons de conception décrivent des solutions standard pour répondre à des problèmes
d'architecture et de conception des logiciels. À la différence d'un algorithme qui s'attache à
décrire d'une manière formelle comment résoudre un problème particulier, les patrons de
conception décrivent des procédés de conceptions généraux. On peut considérer un patron de
conception comme une formalisation de bonnes pratiques, ce qui signifie qu'on privilégie les
solutions éprouvées (un patron de conception n'est considéré comme « prouvé » qu'une fois
qu'il a été utilisé avec succès au moins dans trois cas). [6]
Les design patterns sont tout simplement des architectures de classes permettant d’apporter
une solution à des problèmes fréquemment rencontrés lors des phase d’analyse et de
conception d’application. Ces solutions sont facilement adaptables donc réutilisables. Ils sont
fiables. Ils ont une architectures, facilement compréhensible et identifiable ce qui améliore la
communication et la compréhension entre développeurs.
Les principaux auteurs des design patterns en ont dégagés 23 principaux qui sont plus connus
sous le nom « Gang Of Four », on retrouve une classification en trois catégories :
Les patterns de création : Prototype, singleton, builder...
Les patterns de structure : Façade, Adapter, Bridge…
Les patterns de comportement : Command, Mediator, Observer…
Page 94
Nous nous intéressons dans notre projet aux designs patterns singleton et façade que nous
allons utiliser dans la suite.
4.3.1.1 Singleton
C’est la classe dont nous voulons nous assurer qu’une seule et unique instance de celle-ci est
crée pendant toute la durée d’exécution de notre application. Pour nous assurer de l’unicité de
l’instance de singleton il faut tout d’abord penser à limiter les accès aux constructeurs sinon il
faut que la méthode à implémenter soit statique.
Figure 44 : Architecture de Singleton
Nous allons utiliser ce design pattern dans plusieurs reprises comme la classe qui fait la
connexion à la base de données ou comme le cas de classe écouteur que nous instancions pour
une seule fois.
4.3.1.2 Façade
Une interface unique pour accéder à l'ensemble des composants d'un sous système. Pour la
gestion de nos objets, nous avons eu recours à de nombreux composants différents (des
Factory Methods pour la création d'objets, un gestionnaire de Prototypes, un gestionnaire pour
la mise en cache de certains objets Proxy...). Nous avons alors besoin de simplifier l'interface
permettant d'accéder à ces objets. Pour cela, nous utilisons une Façade.
La Façade consiste à créer une interface unique pour accéder à un sous-système. Elle permet
donc de créer le point d'entrée pour un package. La Façade est unidirectionnelle : de
l'extérieur (les modules utilisant le package) vers l'intérieur (le package lui-même) : Nous
avons utilisé ce dernier dans notre diagramme de classe générale lorsque nous avons utilisé
Page 95
une classe générale qui lie les différents modules hétérogènes qui constituent chacun un
système à part.
Figure 45 : Architecture de façade
4.3.2 Vue dynamique de système
Nous commencons par le diagramme de séquence détaillé d’un scénario nominal de
consultation des mails :
Figure 46 : Diagramme de séquence détaillé de consultation des mails
Page 96
Description de « consulter sa boite mail »
Identification
Nom du scénario: Consulter sa boite mail.
Description : – L’utilisateur accède à sa boite mail puis choisit le type de message qu’il va consulter.
.
– Si l’utilisateur veut consulter les messages qu’il a envoyés l’application consulte la base de
données pour lister les messages.
–Sinon l’application ouvre une connexion TCP/IP avec le serveur POP3.
–Une fois la connexion ouverte, l’utilisateur doit s’authentifier à son compte en envoyant son
login et mot de passe.
– Le serveur POP3 envoie les mails trouvés dans le compte de l’utilisateur.
–Puis l’application envoie une demande de déconnexion.
–La connexion est fermée.
Acteurs : L’employé qui consulte sa boite mail.
Pré conditions : -l’utilisateur doit être authentifié.
-l’utilisateur doit avoir son compte mail et s’authentifie à son compte.
Ensuite nous passons au module de gestion de contacts. Nous avons choisi dans ce module les
deux scénarios suivants : Ajout d’un contact et importation des contacts.
La figure suivante présente le diagramme de séquence détaillé de scénario « ajout d’un
contact ».
Page 97
Figure 47 : Diagramme de séquence détaillé de l’ajout d’un contact
Description d’ « ajout d’un contact »
Identification
Nom du scénario: Ajouter un contact.
Description : – L’utilisateur remplit des champs d’un nouveau contact puis il appuie sur la touche
« ajouter »..
– Un fichier XML sera généré par l’application et contient les données introduites par l’utilisateur, en
même temps une notification sera envoyée à l’administrateur sous la forme d’un mail qui indique que
l’utilisateur X a ajouté le contact Y.
–Le Biztalk qui écoute déjà le répertoire détecte l’arrivée de fichier XML et le passe au
message Box à travers un pipeline puis il fait une copie de fichier et l’envoie à l’orchestration. .
–Dans l’orchestration un traitement se produit et un fichier XML sera généré pour être
envoyé vers le répertoire de sortie mais avant il doit passer par le mapping pour effectuer les valeurs
adéquates de l’ancien fichier XML aux nouveaux champs de fichier XML de sortie.
–Puis l’application java qui est déjà en écoute du répertoire détecte le fichier XML arrivant et
Page 98
extrait ses données.
–Les données extraites sont enregistrées dans la base de données
Acteurs : L’employé qui gère ses contacts.
Pré conditions : -l’utilisateur doit être authentifié.
-l’utilisateur doit créer le groupe où il va ajouter son contact.
Post-conditions : -un contact est créé, une notification est envoyée à l’administrateur.
Nous présentons dans la figure suivante un aperçu de l’orchestration faite sur l’ajout de
contact et de la puissance de BizTalk via ses différents outils comme le mapping,
l’orchestration qui sert à automatiser les règles métiers.
Figure 48 : L’orchestration de l’ajout d’un nouveau contact
Page 99
Le fichier reçu passe par l’orchestration, Biztalk vérifie tout d’abord si le champ photo de
contact est vide ou pas :
- s’il est rempli il passe directement vers la construction de fichier XML de sortie en
utilisant la forme transorfm qui prend comme entrée un fichier XML et comme sortie
un autre fichier XML .Un exemple de mapping présenté ci-dessous illustrera le
mapping entre ces 2 fichiers .
- Sinon une vérification de champ sexe sera faite : si c’est un homme, Biztalk remplit le
champ image par le lien de l’image masculin par défaut sinon il remplit le champ
image par le lien de l’image féminine par défaut. Ensuite le message passe par une
forme Transform et le mapping se produit puis le message sera envoyé vers le port de
sortie.
Le schéma suivant présente un schéma de mapping entre le fichier XML d’entrée et le fichier
de sortie qui sera envoyé à l’application java.
Figure 49: Un cas de mapping
Un Mapping se fait entre ficher XML de contact arrivant de l’application .NET vers le fichier
XML envoyé vers java
Page 100
La figure suivante présente le diagramme de séquence importation des contacts :
Figure 50 : Diagramme de séquence détaillé d’importation d’une liste de contacts
Description d’ « importation de contacts »
Identification
Nom du scénario: Importation de contacts.
Description : – L’utilisateur uploade un fichier texte qui comporte les données de contacts importés.
. – Le fichier texte sera déposé dans le répertoire adéquat.
–Le Biztalk détecte le fichier et le transmet vers le pipeline. .
–Dans le pipeline le fichier passe par le Flat file disassembler où il subit une validation par un
schéma spécifique qui transforme le fichier plat en un fichier XML.
–Biztalk passe le fichier XML au map pour effectuer le mapping puis il génère le nouveau
fichier XML.
–Puis l’application java qui est déjà en écoute du répertoire détecte le fichier XML arrivant et
extrait ses données.
–Les données extraites sont enregistrées dans la base de données
Acteurs : L’employé qui gère ses contacts.
Pré conditions : -l’utilisateur doit être authentifié.
-l’utilisateur doit créer le groupe ou il va ajouter son contact.
Post-conditions : -un contact est crée, une notification est envoyée à l’administrateur.
Page 101
Figure 51 : Diagramme de séquence détaillé d’ajout d’une tâche
Page 102
Description d’ »ajout d’une tâche »
Identification
Nom du scénario: Ajouter une tâche.
Description : – L’utilisateur crée une nouvelle tache.
. – Si la tâche est personnelle une requête est envoyée à la base de données pour enregistrer la
tâche.
–Si la tâche est assignée un fichier XML sera généré et envoyé à un répertoire dont Biztalk
server écoute et détecte le fichier.
–Biztalk envoie le fichier à travers le pipeline vers l’orchestration et un traitement s’effectue au
sein de l’orchestration sur les données reçues.
–Le Biztalk bloque le processus et envoie un fichier XML au répertoire adéquat et attend la
réponse pour débloquer le processus de nouveau.
–L’utilisateur 2 donne son choix soit de valider soit de refuser la tâche et l’application .NET
génère un fichier XML et l’envoie au répertoire sont Biztalk server écoute.
–un traitement s’effectue dans l’orchestration.
–Si l’utilisateur 2 ne valide pas la tache qui a été assignée, une notification sera envoyée à
l’utilisateur 1 pour l’informer.
–Sinon un fichier XML sera généré par le Biztalk et envoyé vers l’application java ou
l’information sera enregistrée dans une autre base de donnée.
Acteurs : L’employé qui gère ses tâches.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : -une tâche est crée ou une notification est envoyée.
Pour ce diagramme de séquence détaillé, nous anons zoomé la partie orchestration pour avoir
une vue de prés sur les traitements que le fichier a subit durant cette étape.
Page 103
Figure 52: l'orchestration des tâches
Ainsi comme on peut le voir sur la figure, le message arrive d’un port d’entrée puis passe par
la forme Transform pour générer un nouveau fichier XML à envoyer à l’application .NET
pour demander la validation de tâche. Lors de l’attente de réponse le processus se bloque et
l’orchestration ne se déclenche pas avant la réception de fichier XML de réponse ce concept
s’appelle la corrélation.
Page 104
Lors de réception de deuxième fichier XML un test se fait pour savoir si la tâche était validée
ou non. Si la tâche est refusée une notification va être envoyée à l’application .NET sinon un
fichier XML sera généré et envoyé à l’application java.
4.3.3 Vue statique de système
Nous allons analyser dans cette partie le diagramme de classe de chaque module en mettant
l’accent sur l lumière sur les attributs et les méthodes de diagramme. Commençons par le
diagramme de classe de gestion de mails :
Figure 53 : Diagramme de classe détaillé de gestion de mails
Page 105
Les relations entre les classes étant déjà décrites dans un chapitre précédant, nous passons
directement à la description des attributs et des méthodes. La classe GestionMailsEnvoyés
contient la méthode GetMailsParMailBox() qui renvoie la liste des mails envoyés enregistrés
dans la base de données, la méthode GetMail() renvoie le contenu du mail sélectionné par
l’utilisateur, enfin la méthode SupprimerMail( ) supprime le mail choisi de la base de
données. La classe mailprofile quant à elle, gère tout ce qui est en lien avec le serveur SMTP
(port, nom de serveur…) . Cette classe permet à l’utilisateur de choisir son serveur SMTP
avec lequel il veut envoyer son message. D’autre part seul l’administrateur peut changer les
caractéristiques d’un serveur SMTP dans la base données ou insérer un nouveau serveur. De
l’autre coté, la classe EnvoieMail comporte trois méthodes : la première EnvoieMail() pour
envoyer un message qui peut comporter une pièce jointe. Une autre méthode
SauvegarderMail() pour sauvegarder les mails envoyés. Enfin la méthode
FromHexaToHTMLUnicode() pour assurer la validité de l’encodage. Pour sa part, l classe
GestionMailsReçus() communique à travers ses méthodes avec le serveur pop3 :
la méthode Connect() assure l’ouverture de connexion physique entre l’application et
le serveur à travers la pile TCP/IP puis la méthode Login() qui prend en paramètres
d’entrée le login et le mot de passe de l’utilisateur pour avoir l’accès à son compte
POP3.
La méthode DownloadMessageHeaders() retourne la collection de messages stockés
dans le compte. Puis la méthode DeleteMessage() qui supprime un message choisit.
La méthode DownloadEntireMessage( ) permet de charger tout les paramètres d’un
message à partir de serveur POP,
la méthode SaveToFolder() permet de sauvegarder les pièces jointes.
la méthode Disconnect() pour déconnecter de serveur. Les autres méthodes ont pour intérêt
de synchroniser entre le serveur POP3 et la base de données par exemple pour vérifier si
l’email listé est chargé de serveur pour la première fois ou bien si l’email est lu ou pas. Nous
passons maintenant au diagramme suivant qui décrit le module gestion des contacts :
Page 106
Figure 54 : Diagramme de classe détaillé de gestion de contacts
Page 107
Le paquetage de l’application .NET :
La classe GestionContactGroupe représente une façade pour gérer les deux classes
principales GestionContacts et GestionGroupe.
La première contient plusieurs méthodes telles que ajouterContact() ,ModifierContact(),
ExporterContacts() et ImportContacts(). La classe CreationDeUserWebEvent() contient les
méthodes de journalisation MembershipUser CreateUser() qui journalise la création d’un
nouveau utilisateur dans le journal de Windows et l’autre méthode
CreationDeUserWebEvent() crée un mail pour l’envoyer comme notification à
l’administrateur lors de création d’un contact.
D’autre part la classe GenerationXML sert à créer des fichiers XML lors de l’ajout, la
modification et la suppression d’un contact.
Le paquetage de l’application JAVA :
L’application java a pour but de recevoir les fichiers XML à partir de Biztalk et d’exécuter
l’action selon le type de fichier reçu. Donc pour la classe DirectoryWatcher nous avons deux
méthodes start() et stop() pour gérer le thread qui écoute le répertoire choisi et une méthode
DirectoryWatcher() qui reçoit comme entrée le chemin de répertoire que l’application va
écouter et l’intervalle de temps après lequel le thread scan le répertoire de nouveau.
La classe FileListener contient des méthodes qui gèrent les événements exercés sur les
fichiers dans le répertoire qui est sous l’écoute. Par exemple la méthode onAdd() contient
l’action faite lorsque le thread détecte un nouveau fichier dans le répertoire.
La classe ParserXML contient des méthodes pour passer les fichiers XML reçus et la classe
ConnexionBD contient les méthodes qui agissent sur la base de données.
Nous présentons ci-après diagramme de classe de module gestion de tâche :
Page 108
Figure 55 : Diagramme de classe détaillé de gestion de tâches
4.4 Conclusion
Au cours de ce chapitre, nous avons approfondies la vision du projet. Nous nous sommes
penchés sur les parties que nous allons être amené à réaliser afin de décortiquer avec le plus
de détail notre application.
Dans le chapitre suivant, nous présenterons les différents choix technologiques que nous
avons faits ainsi que les scénarios les plus importants qu’offre notre projet via les captures
d’écran des interfaces graphiques.
Page 109
CHAPITRE 5
RRééaalliissaattiioonn
1. Introduction
2. Environnement du travail
3. Quelques étapes de réalisations
4. Les problèmes rencontrés
4. Quelques aperçus
5. Chronogramme
Page 110
Chapitre.5 Réalisation
5.1 Introduction
Ce chapitre constitue le dernier volet du rapport du projet de fin d'études. Il a pour objectif
d'exposer le travail achevé. Pour ce faire, nous commençons par la description des outils de
travail. Ensuite, quelques captures d'écran des interfaces. Enfin, nous clôturons ce chapitre par
la présentation du chronogramme des taches réalisées.
5.2 Environnement du travail
5.2.1 Environnement matériel
Les outils matériels utilisés dans notre application sont:
Ordinateur portable NEC e-Motion :
Processeur Intel® Pentium® M processor 1.73GHz.
Une mémoire RAM de 2 GO.
Un disque dur de 80 GO.
Système d’exploitation : fedora® 10
Machine serveur NEC :
Processeur Intel® Pentium® 4 processor 1.73GHz.
Une mémoire RAM de 4 GO.
Un disque dur de 160 GO.
Système d’exploitation : Windows® 2003 Server
5.2.2 Environnement logiciel
Nous avons utilisé comme système d’exploitation le Windows server 2003 qui s’avère être le
meilleur environnement pour l’installation de Biztalk server, en plus nous avons eu recours à
ses serveurs intégrés, configurés dans ce cas tel que le serveur POP3, le serveur SMTP, le
serveur IIS 6 et l’annuaire LDAP.
Page 111
Les outils logiciels utilisés lors de la réalisation de notre projet sont :
o IDE : Eclipse Ganymède et Visual studio 2005.
o L’EAI : Biztalk server 2006 R2.
o SGBD : SQL server 2005, MySQL.
o Editeur UML: Power AMC, MagicDraw UML.
5.2.3 Architecture de la solution
Figure 56: Architecture de la solution
Page 112
Le serveur principal contient le serveur Biztalk 2006 R2 et l’application bureau virtuel
développée en .NET qui est hébergée dans le serveur web IIS 6. Cette dernière communique
avec le serveur de base de données, le serveur de messagerie et les solutions existantes de
gestion de tâches et gestion de contacts qui sont installées sans l’ordinateur qui travaille sur
Fedora .
Le diagramme de déploiement suivant montre d’une façon plus explicite le fonctionnement
de notre solution dans le réseau.
Figure 57: Diagramme de déploiement
Page 113
5.3 Principales étapes de réalisation
Cette section présente les différentes phases de réalisation, le miroir qui reflète notre état
d’esprit lors du développement et de l’intégration de notre application. En effet avant
d’entamer la phase de réalisation nous avons configuré quelques serveurs avec lesquels notre
application interagit.
5.3.1 La phase de préparation
Nous avons commencé par le serveur POP3 que l’utilisateur consulte pour extraire ses
courriers. En fait ce serveur a besoin d’organiser ses domaines d’une façon hiérarchique, c’est
pour cela que nous avons installé le contrôleur de domaine Active Directory, ensuite nous
avons configuré notre serveur et ajouté un domaine pour identifier les comptes des
utilisateurs. Dans notre cas, deux domaines ont été nécessaires : « biztalk.esprit.com »
et « BureauVirtuel.com » pour laisser à l’employé de choisir son domaine.
Dans un deuxième lieu, nous avons mis en place le serveur web IIS 6 dans lequel nous avons
configuré le serveur virtuel SMTP pour l’envoi des courriers.
Ensuite nous avons passé à l’étape d’installation et de configuration la plus importante :
l’installation de Biztalk server 2006 R2 qui a nécessité beaucoup d’effort pour le configurer.
En effet, ce serveur d’intégration nécessite des pré requis pour pouvoir travailler
correctement, comme il nécessite un certain niveau d’accès aux SQL server pour pouvoir
manipuler ses bases de données.
5.3.2 La phase de développement
Dans cette étape nous avons développé trois applications : Une avec le Framework .NET qui
représente notre application principale « Bureau virtuel », les deux autres avec Java et
consistent en deux applications test : « Gestion des contacts » et « Gestion des tâches » pour
mettre en évidence l’intégration et l’utilisation des fonctionnalités déjà existantes.
Dans cette partie nous allons nous focaliser sur l’application « Bureau virtuel » qui a nécessité
le plus d’effort pour pouvoir voir le jour.
Page 114
Lors de mise en place du premier module de gestion de mails nous avons utilisé l’espace de
nom System.Net.Mail qui nous fournit des classes comme MailMessage et SmtpClient
pour garantir l’envoi d’un mail avec un serveur SMTP choisi.
Ensuite lorsque nous avons entamé la partie consultation des mails reçus nous avons rencontré
un problème : Avec quel moyen nous pouvons communiquer avec le serveur POP3 ? En fait,
le Framework .NET 2.0 ne contient pas un espace de nom pour faciliter cette tâche, par
conséquence nous avons été obligés de choisir un chemin parmi ces deux pour résoudre ce
problème. Soit établir la connexion nous même et travailler avec les commandes TCP/IP et
dans ce cas l’obligation de programmer chaque interaction entre le système et le serveur ce
qui peut prendre du temps, soit intégrer un composant déjà développé avec .Net et prêt à être
réutilisé. Naturellement nous avons adopté la deuxième solution et nous avons choisi un
composant qui s’appelle MailBee, ce dernier contient la classe Pop3 qui contient plusieurs
méthodes assurant l’interaction entre notre application et le serveur. Voila ainsi un extrait du
code de notre classe.
Pop3 pop = null;
DataTable table = null;
public string user = null;
public string mdp = null;
MailMessage msg=null;
public void AfficherMails(String mdp, String user)
{
pop = new Pop3();
// Connecter au serveur POP3
pop.Connect("localhost");
pop.Login(user, mdp);
table = new DataTable();
// charger les entétes des messages
MailMessageCollection msgs = pop.DownloadMessageHeaders();
table.Columns.Add("MailId", typeof(String));
table.Columns.Add("From", typeof(String)); table.Columns.Add("To", typeof(String));
table.Columns.Add("Subject", typeof(String));
table.Columns.Add("Date", typeof(DateTime));
table.Columns.Add("Size", typeof(String));
table.Columns.Add("Flagged", typeof(String));
table.Columns.Add("Important", typeof(String));
table.Columns.Add("Flag", typeof(bool));
Page 115
UniqueConstraint clePrim = new UniqueConstraint("contrainte", table.Columns["MailId"], true);
table.Constraints.Add(clePrim);
MailClass mailClass = new MailClass();
bool Flag;
// Pour chaque message dans la liste telechargée depuis le serveur on verifie si ce mail est consulté pour
la première fois ou bien il est déjà lu pour choisir le drapeau adéquat
foreach (MailMessage msg in msgs)
{
int verifier = mailClass.VerifierMail(msg.IndexOnServer);
if (verifier == -10) {
mailClass.InsererNouveauMail(msg.IndexOnServer, 0);
}
Flag = mailClass.RetourneMailFlag(msg.IndexOnServer);
table.Rows.Add(msg.IndexOnServer, msg.From.AsString, msg.To.AsString, msg.Subject, msg.Date,
msg.Size + "octets", false, msg.Priority, Flag);
}
// Disconnect from POP3 server
pop.Disconnect();
}
Ensuite nous avons entamé le module « Gestions de contacts », où nous avons utilisé des
composants ASP.NET tels que le datagrid view et le SQLDataSource ou encore des
contrôles comme DataList qui manque de pagination ce qui peut provoquer un total désordre
lorsque le nombre des contacts augmente. Donc nous avons été obligés de remédier à cette
défaillance et ajouter la pagination nous même.
Dans le module « Gestions de tâches », nous avons développé la possibilité d’assigner une
tâche à un autre utilisateur. Ainsi, pour que ce dernier valide la tâche qui lui est assignée,
l’application doit écouter le répertoire dans le quel le fichier XML va être inséré. Pour assurer
cette fonctionnalité, nous avons utilisé le nom d’espace System.Threading contenant la
classe FileSystemWatcher. Voici un extrait de code de la classe qui assure l’écoute pour
mieux comprendre :
Page 116
String path = HttpContext.Current.Request.PhysicalApplicationPath + "InAjoutTacheValidation\\";
public void MainWatch()
{
FileSystemWatcher watcher = new FileSystemWatcher();
watcher.Path = path;
//mettre un filtre pour écoute les changement de dérniere lecture et acces
watcher.NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.LastWrite
| NotifyFilters.FileName | NotifyFilters.DirectoryName;
// Lorsque un fichier est crée le système leve cet évènement et appelle cette méthode watcher.Created += new FileSystemEventHandler(watcher_Created);
watcher.InternalBufferSize = 16400;
watcher.EnableRaisingEvents = true;
}
public void watcher_Created(object source, FileSystemEventArgs e)
{
object verrou = new object();
//La fonction lock permet d’assure un seul processus peut accéder à notre fichier dans un moment donné
lock (verrou)
{
Thread.Sleep(5);
//Ici on appelle la méthode qui parse le fichier XML pour extraire les données
LectureTache lect = new LectureTache();
lect.FullPath = e.FullPath;
lect.parserFichier();
}
}
On lance le thread qui écoute le répertoire choisi depuis le fichier global de notre application
dans la méthode onStart Application() pour qu’il s’exécute dès le démarrage de l’application
void Application_Start(object sender, EventArgs e)
{ // Code that runs on application startup
Watch wa = new Watch();
System.Threading.ThreadStart delagateTache = new System.Threading.ThreadStart(wa.MainWatch);
System.Threading.Thread TacheThread = new System.Threading.Thread(delagateTache);
TacheThread.Name = "TacheThread";
TacheThread.Start();
}
Page 117
D’autre part, pour assurer la traçabilité de l’application nous avons élaboré des classes de
journalisation comme dans le cas de la création d’un nouvel utilisateur, nous avons utilisé le
nom d’espace System.Diagnostics contenant la classe EventLog qui sauvegarde
l’événement sous format d’observateur d’événements Application
public class LogSqlMembershipProvider : SqlMembershipProvider
{
public LogSqlMembershipProvider()
{
//
// TODO: Add constructor logic here
//
}
public override MembershipUser CreateUser(string username, string password,string email, string
passwordQuestion, string passwordAnswer,bool isApproved, object providerUserKey,out
MembershipCreateStatus status)
{
//Création d’une nouvelle instance d’évènement EventLog log = new EventLog();
//Affectation de l’évènement au journal existant : ‘Application’
log.Log = "Application";
//Créer une nouvelle source en référence à notre application
if (!EventLog.SourceExists("BV"))
{
EventLog.CreateEventSource("BV", "Application");
}
//Affectation de la source à l'évènement
log.Source = "BV";
//Construction du message de l’évènement
string message = "nouvel utilisateur de Bureau virtuel : " + username + " enregistré à : "+ DateTime.Now;
//Ecriture de l’évènement dans le journal Application.
log.WriteEntry(message, EventLogEntryType.Information, 100);
//Rendre la main à la classe de base pour la création de l'utilisateur proprement dite
return base.CreateUser(username, password, email, passwordQuestion,passwordAnswer, isApproved,
providerUserKey, out status);
}
}
Nous continuons dans les besoins techniques de l’application. Nous avons un fichier
Web.conf qui contient plusieurs configurations de notre application. L’une des sections de ce
fichier est la section connectionStrings qui assure la connexion à la base de données, donc le
login et le mot de passe avec lequel on se connecte sont exposés en clair ce qui crée une
défaillance dans le système. C’est pour ce motif là que nous avons développé une classe pour
crypter cette chaine de connexion : La première méthode crypte, la deuxième décrypte.
En voici un exemple :
Page 118
public void ProtectSection(string sectionName,
string provider)
{
Configuration config =
WebConfigurationManager.
OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section =
config.GetSection(sectionName);
if (section != null &&
!section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection(provider);
config.Save();
}
}
public void UnProtectSection(string sectionName)
{
Configuration config =
WebConfigurationManager.
OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section =
config.GetSection(sectionName);
if (section != null &&
section.SectionInformation.IsProtected)
{
section.SectionInformation.UnprotectSection();
config.Save();
}
}
Finalement, dans la partie présentation nous avons utilisé des composants .NET de famille
TELERIK RAD pour une meilleure esthétique.
5.3.3 La phase d’intégration
Après avoir développé les différents modules et composants avec les différents langages, nous
avons entamé la partie intégration. En fait, pour que le fichier arrivant à Biztalk puisse
accéder à ce dernier, il doit être validé par un schéma. Donc nous avons créé les différents
schémas soit pour valider les fichiers XML, soit pour valider les fichiers textes et les convertir
en fichier XML. Ensuite nous avons configuré les « PipeLines » à travers lesquels le fichier
passe vers le composant suivant « le map », c’est pour cela que nous avons créé les différents
map qui assurent le mappage entre le ficher entrant et le fichier sortant comme on peut ajouter
des « functoids » pour rendre le mappage plus souple comme par exemple concaténer deux
Page 119
chaines de caractères et les mettre dans une seule variable, additionner les variables qu’on
choisit du fichier d’entré pour mettre la somme dans une variable dans le fichier de sortie …
Finalement, nous avons entamé une partie très importante : L’orchestration, pour ajouter des
règles métier sur le flux passant entre les applications. Dans cette partie, nous avons fait des
tests, nous avons fait des transformations sur les fichiers et avons utilisé la notion de
corrélation pour bloquer le processus métier jusqu’à recevoir la réponse du fichier envoyé.
Apres avoir achevé le projet d’intégration, nous somme passés au déploiement, mais avant
cela, nous avons donné à notre application une clé que nous avons créé pour crypter les DLL
du projet. Enfin, nous avons consulté la console d’administration de Biztalk server, c’est en ce
moment que nous avons créé les ports physiques et fait le « binding » entre les ports logiques
et les ports physiques.
5.4 Les problèmes rencontrés
Après avoir achevé ce projet, nous pouvons citer les différents problèmes rencontrés :
L’installation délicate de Biztalk server
Le temps énorme que nous avons pris pour nous documenter sur trois
plans
Le manque de documentation autours de Biztalk vu que c’est un EAI
propriétaire, nous avons eu énormément de difficultés pour collecter les
informations et surtout pour corriger les bugs.
Les blocages techniques lors du développement avec ASP.NET et le C#
5.5 Quelques aperçus
Dans cette partie, nous présentons quelques interfaces de l’application
Page 120
Figure 58 : Interface d’authentification
C’est l’interface d’authentification dans laquelle l’utilisateur peut se connecter ou créer un
nouvel utilisateur.
Figure 59 : Interface de gestion de mails
Page 121
L’interface précédente présente la consultation des mails reçus.
Figure 60 : Interface d’affichage de mail
Cette interface présente l’affichage d’un mail sélectionné.
Figure 61 : Interface de gestion de contacts
Page 122
Cette interface présente la gestion des contacts qui liste les différents contacts suivant leur
catégorie et en cliquant sur son nom on peut accéder aux détails de ce dernier.
Figure 62 : Interface d’exporter et importer les contacts
Cette interface montre la possibilité d’exporter la liste de contacts selon le format qu’on veut,
comme on peut importer des contacts à partir d’un fichier texte.
Page 123
5.6 Chronogramme
Période Janvier Février Mars Avril Mai Juin Juillet Aout
Documentation x x x x x x x x x x x x x x x X x x x x x x x x X x x x
Rédaction rapport x x x x
Capture besoins fonctionnels x x x
Capture besoins techniques x x x
Analyse des besoins fonctionnels x x x x X x
Conception générique X x x x
Conception x x x x
Réalisation : modules x x x x x x x
Réalisation : IHM x x x x x X
Réalisation : Biztalk x x X x
Page 124
Conclusion générale
Ce projet de fin d’études, qui s’est déroulé à ESPRITec en collaboration avec le CNI, avait
pour but la conception et la réalisation d’un bureau virtuel dans une architecture et un
environnement favorisant l’interopérabilité.
La solution que nous avons réalisée au bout de ce projet a couvert un certain nombre de
fonctionnalité que peut avoir un bureau virtuel. La principale tâche était de comprendre,
maitriser et implémenter les différents composants de notre serveur d’intégration : Biztalk.
Les difficultés rencontrées au cours de ce projet étaient quasi-quotidiennes. Notre ignorance
du monde des EAI en général et de Biztalk en particulier nous a fait entrer dans une longue
période de documentation .Cette période a coïncidé avec un approfondissement des
connaissances pour la plate-forme .Net. La recherche de la méthodologie appropriée pour
notre projet et la décortication des différentes phases de 2TUP présentaient aussi des phases à
ne pas négliger.
On peut considérer ce projet de fin d’études comme un projet de recherche à travers lequel
nous trouverons l’opportunité d’identifier de nouveaux besoins dans le domaine de
l’interopérabilité.
Les perspectives de ce travail peuvent prendre plusieurs directions. D’une part, nous pouvons
penser à étendre la liste des fonctionnalités du bureau virtuel. D’autre part nous pouvons aussi
utiliser des web services ou utiliser d’autres adaptateurs.
Page 125
Bibliographie & Netographie
Netographie
[1]. http://fr.wikipedia.org/wiki/
[2]. http://www.bea.com
[3]. http://wapedia.mobi/fr/2TUP
[4]. http://www.uml-sysml.org/modelisation-objet/processus-de-modelisation
[5]. caivp.poivron.org/atelier4/caivp-atelier4-courriel.odt
[6]. http://fr.wikipedia.org/wiki/Design_Patterns
Bibliographie
Pascal Roques , Franck Vallée : UML 2 en action 3ème édition : De l'analyse des besoins à la
conception J2EE
Daniel Woolston: Foundations of BizTalk Server 2006
George Dunphy, Ahmed Metwally: Pro BizTalk 2006
Cristian Darie, Zak Ruvalcaba: Build Your Own ASP.NET 2.0 Web Site Using C# & VB
Page 126
Glossaire
A
ASBO (Application Specific Business Object)
Ces données sont appelées Objets de métier spécifiques elles reflètent les données de
l'application (nom du champ, format...).
B
B2B (Business to Business Integration)
Les activités concernant les relations entre des entreprises
BAM (Business Activity Monitoring)
(Monitoring des activités métiers) Fournit un tableau de bord, des indicateurs de mesure de la
performance métier, des outils de monitoring, de reporting et permet le contrôle du rendu
fonctionnel des processus métier , associé de façon classique à un outil de BPM et considéré
à juste titre comme une application à part entière.
BPM (Business Process Management)
On appelle « BPM » (Business Process Management, traduisez littéralement "gestion des
processus métiers ») l'approche consistant à modéliser informatiquement les processus métiers
de l'entreprise, aussi bien dans leur aspect applicatif qu'humain.
C
CRM (Customer Relationship Management)
Gestion de la Relation Clients.
CLR (Common Language Runtime)
C’est le nom choisi par Microsoft pour le composant de machine virtuelle du framework
.NET.
Page 127
E
EAI (Enterprise Application Integration)
Intégration des Applications d’Entreprise qui est utilisé pour l’intégration d’applications en
environnement propriétaire. De moins en moins considéré car remplacé par d’autres
technologies comme BPM, SOA et les applications composites (BAM, etc.).
ERP (Enterprise Resource Planning)
(Planification des Ressources d’Entreprise) Suite d’applications métiers pour le monde de la
Finance, de la gestion des commandes, etc. comme SAP et Oracle.
ESB (Enterprise Service Bus)
Le composant clé dans une suite SOA, où des systèmes et des applications nombreux et variés
doivent se connecter à un backbone et peuvent poster et recevoir des messages/évènements
depuis ce dernier.
F
FTP (File Transfer Protocol)
Un protocole de communication destiné à l'échange informatique de fichiers sur un réseau
TCP/IP. Il permet, depuis un ordinateur, de copier des fichiers vers un autre ordinateur du
réseau, d'alimenter un site web, ou encore de supprimer ou de modifier des fichiers sur cet
ordinateur.
I
IIS (Internet Information Services)
C’est le logiciel de serveur Web (ou HTTP) de la plateforme Windows NT.
J
J2EE (Java 2 Enterprise Edition)
Page 128
Ensemble d'interfaces de programmation orientées objet proposant un modèle pour
l'implémentation des applications d'entreprise. Un acronyme récursif qui signifie en anglais
"Gnu's Not Unix" (littéralement, GNU N'est pas UNIX.
JCA (Java connector architecture)
JCA est la solution de J2EE pour résoudre le problème d’intégration entre le monde J2EE et
le système d’information d’entreprise (EIS).
JMS (Java Message Service)
L'interface de programmation Java Message Service (JMS) permet d'envoyer et de recevoir
des messages de manière asynchrone entre applications ou composants Java. JMS permet
d'implémenter une architecture de type MOM. Un client peut également recevoir des
messages de façon synchrone dans le mode de communication point à point (pour cela, il doit
invoquer la méthode receive() qui est bloquante).
L
LDAP (Lightweight Directory Access Protocol)
Technologie d'accès hiérarchique à toute forme de ressource hébergée dans un annuaire
d'entreprise. Notamment utilisé en matière de sécurité pour stocker les listes d'utilisateurs et
de groupes d'utilisateur avec leurs droits d'accès, ainsi que pour le SSO (Single Sign-On).
M
MOM (Middleware Orienté Messages)
Le terme Message-Oriented Middleware (MOM) désigne une famille de logiciels qui
permettent l'échange de messages entre les applications présentes sur un réseau informatique.
Les MOM font partie des éléments techniques de base des architectures informatiques. Ils
permettent une forme de couplage faible entre applications.
P
POP3 (Post Office Protocol Version 3)
Un protocole qui permet de récupérer les courriers électroniques situés sur un serveur de
messagerie électronique.
Page 129
Cette opération nécessite une connexion à un réseau TCP/IP. Le port utilisé est le 110.
Q
QoS (Quality of Service)
La qualité de service (QoS, Quality of Service) est la capacité à véhiculer dans de bonnes
conditions un type de trafic donné, en termes de disponibilité, débit, délais de transmission,
gigue, taux de perte de paquets…
R
RCP (Rich Client Platform)
Désigne un type de plate-formes de développement pour la réalisation d'applications,
exemple : Eclipse.
RUP (Rational Unified Process)
Une méthode de développement par itérations promue par la société Rational Software,
rachetée par IBM.
S
SMS (Short Message Service)
Messages courts qui peuvent être envoyés et reçus sur des téléphones mobiles GSM.
SMTP (Simple Mail Transfer Protocol)
Protocole pour envoyer des courriers électroniques sur Internet.
SOA (Service-Oriented Architecture)
Un concept architectural moderne pour les entreprises dans lesquelles des fonctionnalités
fournies par des applications variées sont disponibles de façon autonome, avec des services
aux couplages lâches présentant des interfaces bien définies.
SOAP (Simple Object Access Protocol)
(Protocole d’Accès aux Objets) Format d’encodage pour l’invocation distante dans le cadre de
l’envoi et de la réception de messages.
Page 130
SSL (Short Message Service)
Messages courts qui peuvent être envoyés et reçus sur des téléphones mobiles GSM.
SSO (Single Sign On)
Dispositif permettant à un utilisateur d'accéder à des services divers en ne s'identifiant qu'une
seule fois.
SCM (Supply Chain Management)
(Gestion de la Chaîne d’Approvisionnement) Applications métiers pour la gestion de la
chaîne de valeur (livraisons et commandes) au sein d’une chaîne commerciale de type
fournisseur-vendeur.
SLA (Service Level Agreement)
C’est un indicateur de qualité précisé dans un contrat de prestation de service entre un
fournisseur (par exemple un infogérant) et son client.
U
UML (Unified Modeling Language)
C’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.
W
WCF (Windows Communication Foundation)
C'est l'un des 4 composants majeurs du .NET Framework 3.0 (avec WPF, CardSpace et WF).
WSDL (Web Services Definition Language)
(Langage de Définition des Services Web) Le standard de définition des interfaces pour les
Web Services.
X
Page 131
XML (Extensible Markup Language)
Le méta-langage de base pour toutes les technologies SOA et présent dans la plupart des
standards associés.
XP (Extreme Programming)
C’est une méthode agile de gestion de projet informatique adaptée aux équipes réduites avec
des besoins changeants. Elle pousse à l'extrême des principes simples.
XMI (XML Metadata Interchange)
C’est un standard pour l'échange d'informations de métadonnées UML basé sur XML.
XSLT (XML Stylesheet Transformation)
Un langage XML standardisé utilisé pour stocker la définition et pour exécuter les
transformations de messages de format à format.
Page 132
ANNEXES
Page 133
2TUP
2TUP signifie « 2 Track Unified Process ». C’est un processus UP qui répond aux
caractéristiques que nous venons de citer. Le processus 2TUP apporte une réponse aux
contraintes de changement continuel imposées aux systèmes d’information de l’entreprise.
En ce sens, il renforce le contrôle sur les capacités d’évolution et de correction de tels
systèmes. « 2 Track » signifie littéralement que le processus suit deux chemins. Il s’agit
des chemins « fonctionnels » et « d’architecture technique », qui correspondent aux deux
axes des changements imposés au système informatique.
Le système d'information soumis à deux natures de contraintes
L’axiome fondateur du 2TUP consiste à constater que toute évolution imposée au système
d’information peut se décomposer et se traiter parallèlement, suivant un axe fonctionnel
et un axe technique. Pour illustrer cet axiome, prenons les trois exemples suivants :
1. une agence de tourisme passe des accords avec une compagnie aérienne de sorte que le
calcul des commissions change. En l’occurrence, les résultats issus de la branche
fonctionnelle qui évoluent pour prendre en compte la nouvelle spécification.
2. cette même entreprise décide d’ouvrir la prise de commande sur le Web. Si rien ne change
fonctionnellement, en revanche, l’architecture technique du système évolue ;
3. cette entreprise décide finalement de partager son catalogue de prestations avec les vols
de la compagnie aérienne. D’une part, la fusion des deux sources d’informations
Annexe
A
Page 134
imposera une évolution de la branche fonctionnelle, d’autre part, les moyens techniques
de synchronisation des deux systèmes conduiront à étoffer l’architecture technique du
système. L’étude de ces évolutions pourra être menée indépendamment, suivant les deux
branches du 2TUP À l’issue des évolutions du modèle fonctionnel et de l’architecture
technique, la réalisation du système consiste à fusionner les résultats des deux branches.
Cette fusion conduit à l’obtention d’un processus de développement en forme de Y, comme
illustré par la figure suivante.
Le processus de développement en Y
La branche gauche (fonctionnelle) comporte :
la capture des besoins fonctionnels, qui produit un 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. De son côté, la maîtrise d’œuvre consolide les spécifications et en vérifie la
cohérence et l’exhaustivité l’analyse, qui consiste à étudier précisément la spécification
fonctionnelle de manière à obtenir une idée de ce que va réaliser le système en termes de
métier. Les résultats de l’analyse ne dépendent d’aucune technologie particulière.
La branche droite (architecture technique) comporte :
la capture des besoins techniques, qui recense toutes les contraintes et les choix
dimensionnant la conception du système. Les outils et les matériels sélectionnés ainsi
que la prise en compte de contraintes d’intégration avec l’existant conditionnent
généralement des prérequis d’architecture technique ;
Page 135
• la conception générique, qui définit ensuite les composants nécessaires à la construction de
l’architecture technique. Cette conception est la moins dépendante possible des aspects
fonctionnels. Elle a pour objectif d’uniformiser et de réutiliser les mêmes mécanismes
pour tout un système.
L’architecture technique construit le squelette du système informatique et écarte la plupart des
risques de niveau technique. L’importance de sa réussite est telle qu’il est conseillé de réaliser
un prototype pour assurer sa validité.
La branche du milieu comporte :
La conception préliminaire, qui représente une étape délicate, car elle intègre le
modèle d’analyse dans l’architecture technique de manière à tracer la cartographie des
composants du système à développer.
la conception détaillée, qui étudie ensuite comment réaliser chaque composant.
L’étape de codage, qui produit ces composants et teste au fur et à mesure les unités de
code réalisées ;
l’étape de recette, qui consiste enfin à valider les fonctions du système
développé.
LES BRANCHES DU “Y” PRODUISENT DES MODÈLES RÉUTILISABLES
La branche gauche capitalise la connaissance du métier de l’entreprise. Elle constitue
généralement un investissement pour le moyen et le long terme.
Les fonctions du système d’informations sont en effet indépendantes des technologies
utilisées. Cette évidence n’a malheureusement pas souvent été mise en pratique, car dans bien
des cas, la connaissance fonctionnelle d’un produit se perd dans les milliers de ligne de code
de sa réalisation.
L’entreprise qui maintient le modèle fonctionnel de sa branche gauche est pourtant à même
de le réaliser sous différentes technologies. Il suffit de « greffer » une nouvelle
architecture technique pour mettre à jour un système existant.
Page 136
La branche droite capitalise quant à elle un savoir-faire technique. Elle constitue un
investissement pour le court et le moyen terme. Les techniques développées pour le
système peuvent l’être en effet indépendamment des fonctions à réaliser.
L’architecture technique est d’ailleurs de moins en moins la préoccupation des services
informatiques dont l’entreprise n’a pas vocation à produire du code. L’existence de produits
tels que les serveurs d’application ou la standardisation des services Web reflète cette
tendance à pouvoir disposer sur le marché d’architectures techniques « prêtes à intégrer ».
Une architecture technique est en effet immédiatement réutilisable pour les différentes
composantes fonctionnelles d’un même système d’entreprise.
Page 137
Les designs patterns
De nombreuses méthodes existent pour simplifier la phase de conception des logiciels. Parmi
les plus connues, considérons Merise et UML.
Mais une autre méthode existe, plus proche de l'implémentation. Lors de la conception d'une
application de nombreux problèmes peuvent survenir. Le système des Design Patterns, ou
motifs de conception, représente un système objet destiné à la résolution de problèmes
techniques. Un design pattern constitue un petit ensemble de classes apte à offrir la solution la
plus efficace à un problème. La définition d'un motif de conception repose donc sur trois
critères. Premièrement, le problème à résoudre est classique et bien connu. Ensuite,
l'ensemble des classes employées porte un nom unique (on parle par exemple du motif
"Decorator"). Enfin, la solution que propose ce motif correspond à la résolution la plus
optimale du problème. Les designs patterns proviennent du travail de nombreux développeurs
qui se sont tour à tour penchés sur les mêmes problèmes. En mettant en corrélation ces
travaux on a pu désigner les meilleures solutions découvertes sous le terme de motifs de
conception. La connaissance de ces motifs permet au programmeur de trouver rapidement des
implémentations pour ses programmes. La principale difficulté réside dans l'identification du
problème et dans sa mise en relation avec des motifs connus.
Pour résumer, les motifs de conception servent à offrir un catalogue de solutions objets, à
identifier ces solutions pour faciliter le dialogue entre architectes logiciels et pour tirer
pleinement parti des caractéristiques de la programmation objet.
Le motif Façade
Le motif Façade appartient au groupe de motifs structurels. De manière générale, l'évolution
et le développement d'un programme impliquent l'accroissement de sa complexité.
L'implication des motifs de conception dans la réalisation d'un logiciel participe bien souvent
à la génération de nombreuses classes supplémentaires. Pour pallier cette complexité, les
Annexe
B
Page 138
développeurs rédigent usuellement des sous-systèmes constituant des ensembles de classes
puissants et flexibles. Toutefois, leur emploi se caractérise lui-même par une forte complexité
due à l'éclatement des fonctionnalités. Afin d'offrir une interface unifiée à un sous-système,
les concepteurs se doivent d'opter pour le Design Pattern nommé Façade.
Une Façade consiste en une simple interface de programmation destinée à fournir une
utilisation par défaut du sous-système. La principale caractéristique de la Façade réside dans
sa forte indépendance vis-à-vis du sous-système. Les classes inhérentes au système ne
connaissent pas l'existence de cette Façade et n'y font jamais référence. De fait, l'utilisateur du
sous-système ne se voit pas bridé par l'existence de cette Façade. Nous devons nous voir
octroyer la possibilité de la contourner pour employer directement les interfaces mêmes du
sous-système.
Un exemple définitivement trivial de système pouvant bénéficier d'une Façade concerne
l'accès aux bases de données. Notre exemple emploie le langage C# et propose un code source
affichant le contenu d'une table qui est au sein d'une base de données Access locale. Pour
parvenir à ce résultat, le programme doit en premier lieu effectuer une jonction vers la base de
données par l'entremise du driver approprié. Une fois la connexion effectuée, nous devons
mettre en place une requête que nous fournirons à un adaptateur. Le rôle de ce dernier
consistera à fournir les résultats de la requête au sein d'un ensemble de données (un DataSet).
Vous trouverez trace de ces pérégrinations dans le listing numéro trois.
La gestion de ce sous-système (composé de l'interface de connexion, de l'interface de
requêtes, etc.) nécessite la mise en ouvre de plusieurs classes fort différentes. Il en résulte un
code relativement indigeste et plutôt rigide. Afin de simplifier l'utilisation des accès aux bases
de données, nous optons pour la création d'une Façade. Le rôle exact de la Façade consiste à
encapsuler le code que nous venons de voir pour le rendre plus accessible. L'interface
contenue dans le listing numéro quatre présente une généralisation de l'exemple que nous
venons d'aborder.
Grâce à cette façade nous pourrons alors rédiger les instructions suivantes :
Facade.Databse db = new Facade.Database("Microsoft.Jet.OLEDB.4.0");
db.Open("Authors.mdb");
DataSet ds = db.ExecuteQuery("SELECT * FROM Authors");
db.Close();
Page 139
Le code source que nous obtenons de la sorte se révèle bien plus lisible que le précédent.
Toutefois, l'application de notre Façade implique une spécialisation du code. Gardez donc
bien à l'esprit lors de la conception d'une Façade que celle-ci doit correspondre au cas le plus
courant de l'utilisation de votre sous-système.
Le motif Façade ouvre un accès simplifié à un sous-système.
Le motif Singleton
Le design pattern Singleton se voit regroupé au sein des motifs de création. Il s'agit en réalité
d'un motif de "non-création". En programmation orientée objet, il existe de nombreuses
circonstances au cours desquelles il convient de ne posséder qu'une seule et unique instance
d'une classe donnée. Un programme ne doit proposer par exemple qu'un seul gestionnaire de
cache.
L'implémentation de ce motif peut bénéficier de trois approches possibles. Ces trois
approches ont en commun l'emploi de membres statiques de classe. La première approche
repose sur le principe des exceptions. Analysons le listing d'une implémentation possible d'un
gestionnaire de cache :
public class CacheManager {
protected static boolean isInstanceAlive = false;
public CacheManager() throws SingletonException {
if (isInstanceAlive)
throw new SingletonException("instance de CacheManager deja active");
else
isInstanceAlive = true;
System.out.println("Le cache a ete cree avec succes.");
}
public void finalize() {
Page 140
isInstanceAlive = false;
}
}
Lors de l'appel du constructeur, nous vérifions au préalable qu'aucune instance n'existe déjà.
L'existence d'une instance se détermine par la valeur de la variable logique "isInstanceAlive".
Si une instance a déjà été créée, le constructeur émet une exception pour le signaler.
L'utilisation d'une exception est rendue obligatoire par l'impossibilité d'un constructeur de
renvoyer une valeur.
La seconde approche possible pour implémenter le modèle Singleton consiste à prendre
exemple sur la classe java.lang.Math. Java offre en effet un mot clé particulier interdisant
l'héritage d'une classe. Il s'agit du mot clé "final". En créant une classe "final" ne contenant
que des méthodes statiques, vous vous assurez de l'impossibilité d'en créer une instance.
Il se révèle possible de créer des instances de la classe. Néanmoins, chaque instance possédera
le même comportement que les autres, puisque l'héritage sera interdit. Cette approche pêche
par sa difficulté d'adaptation lorsque l'on souhaite retirer le principe du Singleton. Un exemple
simple de ce procédé peut être :
final class FinalCacheManager
{
static void printCacheContent() {
System.out.println("Le contenu du cache est le suivant : <vide>");
}
}
La troisième et dernière approche rappelle le principe de la fabrique. Il s'agit de réaliser une
méthode statique garantissant l'impossibilité de créer deux instances de la classe. L'avantage
de cette dernière manière de procéder réside dans la possibilité de laisser de côté le traitement
des exceptions. Ceci a pour effet bénéfique de rendre le code plus léger à rédiger et à
comprendre. Remplacez donc le constructeur de la classe CacheManager par une méthode
telle que celle-ci :
public static StaticCacheManager getInstance()
{
if (isInstanceAlive)
return null;
else {
isInstanceAlive = true;
return new StaticCacheManager();
}
}
Page 141
Le principe du Singleton amène deux conséquences importantes. En premier lieu, l'héritage
d'un singleton se voit possible (hormis dans le cadre de la seconde approche) mais difficile
dans la mesure où la classe de base ne doit pas avoir été instanciée. Ensuite, vous pouvez tout
à fait décider d'étendre le Singleton pour permettre la création de quelques instances au lieu
d'une seule.
Page 142
SOA
Le système d'information de l'entreprise est généralement constitué d'applications et de
données constituant son héritage (en anglais legacy). Avec les fusions de groupe, l'évolution
des technologies, cet héritage a tendance à devenir hétérogène et à se spécialiser par métier
(entité, service, etc.), ce qui provoque un fonctionnement en silo, c'est-à-dire un
cloisonnement des différents métiers empêchant certaines formes de transversalité et
masquant au décideur une vision globale du système d'information de son entreprise.
L'intégration des applications de l'entreprise (EAI) est une solution à ce problème. Elle
consiste à développer des connecteurs spécifiques permettant de faire communiquer entre-eux
les différents silos de l'entreprise.
Architecture orientée service
Une architecture orientée services (notée SOA pour Services Oriented Architecture) est une
architecture logicielle s'appuyant sur un ensemble de services simples.
L'objectif d'une architecture orientée services est donc de décomposer une fonctionnalité en
un ensemble de fonctions basiques, appelées services, fournies par des composants et de
décrire finement le schéma d'interaction entre ces services.
L'idée sous-jacente est de cesser de construire la vie de l'entreprise autour d'applications pour
faire en sorte de construire une architecture logicielle globale décomposées en services
correspondant aux processus métiers de l'entreprise. Lorsque l'architecture SOA s'appuie sur
des web services, on parle alors de WSOA, pour Web Services Oriented Architecture).
Principes généraux d'une architecture orientée service :
Il n'existe pas à proprement parler de spécifications officielles d'une architecture SOA,
néanmoins les principales notions fédératrices que l'on retrouve dans une telle architecture
sont les suivantes :
Annexe
C
Page 143
La notion de service, c'est-à-dire une fonction encapsulée dans un composant que l'on
peut interroger à l'aide d'une requête composée d'un ou plusieurs paramètres et
fournissant une ou plusieurs réponses. Idéalement chaque service doit être indépendant
des autres afin de garantir sa réutilisabilité et son interopérabilité.
La description du service, consistant à décrire les paramètres d'entrée du service et le
format et le type des données retournées. Le principal format de description de
services est WSDL (Web Services Description Language), normalisé par le W3C.
La publication (en anglais advertising) et la découverte (discovery) des services. La
publication consiste à publier dans un registre (en anglais registry ou repository) les
services disponibles aux utilisateurs, tandis que la notion de découverte recouvre la
possibilité de rechercher un service parmi ceux qui ont été publiés. Le principal
standard utilisé est UDDI (Universal Description Discovery and Integration),
normalisé par l'OASIS.
L'invocation, représentant la connexion et l'interaction du client avec le service. Le
principal protocole utilisé pour l'invocation de services est SOAP (Simple Object
Access Protocol).
Avantages d'une architecture orientée service
Une architecture orientée services permet d'obtenir tous les avantages d'une architecture
client-serveur et notamment :
Une modularité permettant de remplacer facilement un composant (service) par un
autre.
Une réutilisabilité possible des composants (par opposition à une système tout-en-un
fait sur mesure pour une organisation).
De meilleures possibilités d'évolution (il suffit de faire évoluer un service ou d'ajouter
un nouveau service)
Une plus grande tolérance aux pannes
Top Related