143
Page 1 T T a a b b l l e e d d e e s s m m a a t t i i è è r r e e s s 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

Bureau virtuel

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

Page 14

CHAPITRE 2

EEttaatt ddee ll’’aarrtt

1. Introduction

2. Etude comparative

3. Choix de méthodologie

4. Conclusion

Page 15: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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

email

adresse

dateDeNaissance

login

mp

numGSM

numFax

: int

: String

: String

: long

: String

: String

: Date

: String

: String

: int

: int

Page 61: Bureau virtuel

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

email

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: Bureau virtuel

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: Bureau virtuel

Page 63

Diagramme d’activité de « envoie SMS »

Consulter calendrier collègue

Page 64: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

Page 85

CHAPITRE 4

CCoonncceeppttiioonn

1. Introduction

2. Conception préliminaire

3. Conception détaillée

4. Conclusion

Page 86: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

Page 101

Figure 51 : Diagramme de séquence détaillé d’ajout d’une tâche

Page 102: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

Page 106

Figure 54 : Diagramme de classe détaillé de gestion de contacts

Page 107: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

Page 132

ANNEXES

Page 133: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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: Bureau virtuel

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