Carlo Abi Chahine Sylvain Archenault Yves Houpert Martine Wang

R APPORT DE CONCEPTION UML : Bamboo Ch@t

Projet GM4 Juin 2006

Table des matires

1 2 Introduction Prsentation du logiciel 2.1 Prcisions sur le protocole de communication . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Prcisions sur les threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . tude de conception UML du logiciel 3.1 Schma entre-sortie . . . . . . . . . . . . . . . 3.2 Business model . . . . . . . . . . . . . . . . . . 3.3 Les cas dutilisations . . . . . . . . . . . . . . . 3.4 Diagrammes dactivit . . . . . . . . . . . . . . 3.4.1 Inscription et connexion BambooCh@t 3.4.2 Ajout dun contact . . . . . . . . . . . . 3.4.3 Suppression dun contact . . . . . . . . . 3.4.4 Envoi dun message . . . . . . . . . . . 3.5 Diagrammes de squences . . . . . . . . . . . . 3.5.1 Connexion (Partie Cliente) . . . . . . . . 3.5.2 Connexion (Partie Serveur) . . . . . . . . 3.5.3 Envoi dun message (Partie Cliente) . . . 3.5.4 Envoi dun message (Partie Serveur) . . . 3.5.5 Rception dun message . . . . . . . . . 3.5.6 Ajouter un contact (Partie Cliente) . . . . 3.5.7 Ajouter un contact (Partie Serveur) . . . 3.6 Diagrammes de classes . . . . . . . . . . . . . . 3.6.1 Les diagrammes de classes . . . . . . . . 3.6.2 Les paquetages . . . . . . . . . . . . . . 3.7 Diagrammes de collaborations . . . . . . . . . . 3.7.1 Envoi dun message . . . . . . . . . . . 3.7.2 Rception dun message ( Partie Serveur) 3.7.3 Rception dun message (Partie Cliente) . 3.8 Diagrammes dtats-transitions . . . . . . . . . . 3.8.1 mission du message . . . . . . . . . . . 3.8.2 Serveur/Client . . . . . . . . . . . . . . 3.8.3 Rception du message . . . . . . . . . . Conclusion 2 3 3 3 4 4 5 6 7 7 8 9 10 11 11 12 13 14 15 15 16 17 17 22 23 23 24 25 26 26 27 27 28

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-1-

Chapitre 1

Introduction
Ce rapport illustre ltude de conception UML de lun de nos projets raliss au cours de cette anne. Dans un premier temps, nous prsenterons ce projet et ses fonctionnalits pour bien dnir la problmatique. Ensuite, nous exposerons les diffrents travaux UML que nous avons effectus et qui permettront de bien structurer la ralisation du projet. Ces diagrammes seront accompagns dexplications pour une meilleure comprhension. Enn, nous conclurons ce rapport en dtaillant les bnces que lont peut tirer dune telle tude et les raisons qui font que UML est un langage trs souvent utilis par les dveloppeurs lors de la conception de logiciels complexes.

-2-

Chapitre 2

Prsentation du logiciel
Dans le cadre de loption Java, nous avons souhait dvelopper un systme de messagerie instantane crypte . Voici une prsentation gnrale du projet BambooCh@t sur lequel nous avons ralis notre tude de conception UML. Le logiciel est compos de 2 applications distinctes : lapplication Client et lapplication Serveur. Lapplication Client consistera en une petite fentre dans laquelle lutilisateur pourra communiquer avec les autres utilisateurs. De plus, il aura sa disposition la liste des personnes connectes. Il aura galement la possibilit dutiliser quelques options lies par exemple au cryptage des communications. Lapplication Serveur aura, quant elle, le rle de connecter les utilisateurs entre eux, de grer les connexions (par mot de passe). Elle permettra galement de rcuprer les clefs publiques des autres utilisateurs. De plus, elle implmentera un mini-site permettant ladministration, la gestion des utilisateurs, la recherche des cls publiques, linscription, la gnration des clefs,... Il y a une troisime application importante qui est incorpore au serveur, il sagit dun Entreprise Java Bean (EJB). Celui-ci est en charge de grer la base de donnes.

2.1

Prcisions sur le protocole de communication

Il est galement important de dtailler le mode de communication entre le client et le serveur an de faciliter la comprhension des diagrammes, ceux-ci tant souvent allegs des dtails des communications rseaux. An de communiquer, les deux applications utilisent des objets. On peut distinguer trois type dobjets principaux : Message : Message dun client un de ses contacts. Requtes : Une demande dun client pour ajouter un contact, changer son statut, ... Rponse : Rponse du serveur suite une requte. Pour transiter sur le rseau, ces objets ont besoin de subir une transformation. On les crit en XML avant de les envoyer, puis on les rcre la rception. Ce mcanisme a souvent t omis dans les diagrammes.

2.2

Prcisions sur les threads

An davoir un serveur performant pouvant traiter plusieurs requtes la fois, nous avons utilis des threads. Ceux-ci ne se sont pas faciles reprsenter dans les scnarios. Cest pourquoi nous avons prcis laide dun commentaire lorsquune mthode est excute dans un thread.

-3-

Chapitre 3

tude de conception UML du logiciel

3.1 Schma entre-sortie

Le schma dentre-sortie est le diagramme le plus gnral du langage UML. Celui prsente uniquement les fonctionnalits de lapplication ainsi que le rsultat que lon obtiendra. BambooCh@t permettra donc lutilisateur de sinscrire (et ultrieurement de se connecter) puis denvoyer et de recevoir des messages.

-4-

III tude de conception UML du logiciel : Business model

3.2

Business model

F IG . 3.1 Business Model

-5-

III tude de conception UML du logiciel : Les cas dutilisations

3.3

Les cas dutilisations

Les cas dutilisations permettent de dcrire le comportement dun systme du point de vue de lutilisateur.

F IG . 3.2 Les diffrents cas dutilisation

-6-

III tude de conception UML du logiciel : Diagrammes dactivit

3.4
3.4.1

Diagrammes dactivit
Inscription et connexion BambooCh@t

La connexion BambooCh@t est bien sr diffrente si lutilisateur utilise le logiciel pour la premire fois ou sil est dj rpertori dans la base de donnes. Dans le premier cas, la personne devra suivre les diffrentes dmarches pour sinscrire. En revanche, si lutilisateur possde dj un compte, il aura accs directement sa liste de contacts.

F IG . 3.3 Connexion BambooCh@t

-7-

III tude de conception UML du logiciel : Diagrammes dactivit

3.4.2

Ajout dun contact

Lapplication permet lutilisateur de grer ses contacts. Lorsque celui-ci dsire ajouter un contact dans sa liste, une fentre Ajouter Contact apparat. Lutilisateur saisit les coordonnes du nouveau conctact pour que celui-ci soit enregistr dans la base de donnes. Ensuite, le contact ajout apparat sur la liste de contacts de lutilisateur.

F IG . 3.4 Ajouter un contact

-8-

III tude de conception UML du logiciel : Diagrammes dactivit

3.4.3

Suppression dun contact

La possibilit de supprimer un contact est la 2me grande fonctionnalit qui permet lutilisateur de grer sa liste. Celle-ci est trs simple puisquil suft de le slectionner puis de cliquer sur Supprimer contact . Celui-ci sera galement supprim dans la base de donnes.

F IG . 3.5 Supprimer un contact

-9-

III tude de conception UML du logiciel : Diagrammes dactivit

3.4.4

Envoi dun message

Lenvoi de message est la fonctionnalit principale de BambooCh@t mais galement la plus complexe. En effet, lutilisateur peut tout dabord choisir sil dsire ou non crypter le message. Dans un deuxime temps, lorsque le serveur aura rcupr le message, lapplication devra savoir si la conversation est dj entame (dans ce cas, on afche le message dans la fentre correspondante) ou non. Dans ce cas prcis, on affectera un numro de fentre la future conversation. On ouvrira celle-ci et le message safchera lintrieur.

F IG . 3.6 Envoyer un message

- 10 -

III tude de conception UML du logiciel : Diagrammes de squences

3.5

Diagrammes de squences

Les diagrammes de squences permettent de reprsenter la squence des interactions entre plusieurs objets impliqus dans une fonctionnalit particulire du logiciel. Nous avons chaque fois choisi de sparer la partie Client et la partie Serveur pour que les diagrammes soient plus clairs. Les scnarios sont donc en quelque sorte scinds en deux pour bien dcomposer les deux applications.

3.5.1

Connexion (Partie Cliente)

Le processus de connexion contient trois phases. Tout dabord, le socket doit se connecter au serveur, puis le client envoie ses identiants et enn, il doit rcuprer la liste de ses contacts. Lutilisateur et le serveur jouent bien leur rle dacteur.

F IG . 3.7 Connexion BambooCh@t (Client)

- 11 -

III tude de conception UML du logiciel : Diagrammes de squences

3.5.2

Connexion (Partie Serveur)

F IG . 3.8 Connexion BambooCh@t (Serveur)

- 12 -

III tude de conception UML du logiciel : Diagrammes de squences

3.5.3

Envoi dun message (Partie Cliente)

Lenvoi dun message est la fonctionnalit de base de lapplication. Elle est relativement simple. Ici nous voyons le chemin suivi par le message de lexpditeur jusquau serveur. La rception sera traite dans la section suivante.

F IG . 3.9 Envoyer un message (Client)

- 13 -

III tude de conception UML du logiciel : Diagrammes de squences

3.5.4

Envoi dun message (Partie Serveur)

Lorsque le message arrive dans le serveur sous format XML, il faut le dcoder pour le transformer en MessageContent. Ensuite, on cherche et on rcupre le destinataire du message. Le message est alors renvoy au serveur de nouveau sous format XML.

F IG . 3.10 Envoyer un message (Serveur)

- 14 -

III tude de conception UML du logiciel : Diagrammes de squences

3.5.5

Rception dun message

Lorsque lon reoit un message du serveur, on recherche la fentre correspondant la connexion, ou on en cre une nouvelle si elle nexiste pas. Puis on afche le message dans cette fentre.

F IG . 3.11 Rception dun message

3.5.6

Ajouter un contact (Partie Cliente)

Ce scnario reprsente comment marche lajout dun contact. Lajout est effectu en deux tapes : la demande (ce que lon voit ici) et la rponse (partie suivante). Dans cette partie, on se contente denvoyer le nom du contact que lon souhaite ajouter.

F IG . 3.12 Ajout dun contact (Client)

- 15 -

III tude de conception UML du logiciel : Diagrammes de squences

3.5.7

Ajouter un contact (Partie Serveur)

Ici nous voyons comment le serveur traite lajout dun contact par un utilisateur. Une fois la demande reue et analyse, on effectue les changements ncessaires dans la base de donnes par lintermdiaire dun EJB (Entreprise Java Bean), puis on renvoie une rponse au client.

F IG . 3.13 Ajout dun contact (Serveur)

- 16 -

III tude de conception UML du logiciel : Diagrammes de classes

3.6
3.6.1

Diagrammes de classes
Les diagrammes de classes

Les diagrammes de classes sont les diagrammes les plus connus du langage UML. Ils permettent dapprhender, dun point de vue logique, la structure statique du systme en indiquant : - la structure des objets composant lapplication - les liens structurels entre les objets Nous allons ici prsenter les classes illustrant la hirarchie entre les messages. Nous avons divis les classes en trois diagrammes an de faciliter la lecture.

- 17 -

III tude de conception UML du logiciel : Diagrammes de classes

F IG . 3.14 Diagramme des classes Message

- 18 -

III tude de conception UML du logiciel : Diagrammes de classes

F IG . 3.15 Diagramme des classes : Requtes - 19 -

III tude de conception UML du logiciel : Diagrammes de classes

F IG . 3.16 Diagramme des classes : Rponse

- 20 -

III tude de conception UML du logiciel : Diagrammes de classes

F IG . 3.17 Diagramme des classes : Analyse XML - 21 -

III tude de conception UML du logiciel : Diagrammes de classes

3.6.2

Les paquetages

F IG . 3.18 Paquets

- 22 -

III tude de conception UML du logiciel : Diagrammes de collaborations

3.7

Diagrammes de collaborations

Ils fournissent une reprsentation synthtique des interactions entre les objets.

3.7.1

Envoi dun message

Lenvoi du message est en quelque sorte la phase antrieure la rception du message. La fentre dans laquelle on a pass le message envoie le message au coeur de lapplication : la classe KernelMessenger. Cette classe gre linterface entre le graphique et le programme en lui-mme. Le message est alors cod en XML laide de la mthode toXML(). Le message sous cette forme est envoy au serveur pour tre trait de la manire suivante.

F IG . 3.19 Envoyer un message

- 23 -

III tude de conception UML du logiciel : Diagrammes de collaborations

3.7.2

Rception dun message ( Partie Serveur)

Le droulement de cette action est centr autour des PoolWorker. Pour bien comprendre ce quest un PoolWorker, il faut expliquer la notion de ThreadPool. Un ThreadPool est une sorte de bassin o interagissent un ensemble de PoolWorker. Ds quune action doit tre excute, un des threads disponible (un PoolWorker) leffectue. Si tous les PoolWorker sont dj occups, le premier qui deviendra libre soccupera de la tche. Pendant ce temps, la tche est mise en attente. Le Socket reoit donc le message sous format XML. Le message est ensuite pass un PoolWorker disponible. Celui-ci le dcode pour le traduire en type MessageContent laide de XMLParser. Puis, on rcupre le destinataire. Enn, on retransforme le message en XML avant de lenvoyer au client. Il est important de noter que lorsque le message est crypt, des modications sont effectues sur le contenu du message.

F IG . 3.20 Rception dun message (Partie serveur)

- 24 -

III tude de conception UML du logiciel : Diagrammes de collaborations

3.7.3

Rception dun message (Partie Cliente)

La partie Client est plus facile. Elle est base sur la classe KernelMessenger. Le socket envoie le message sous format XML au KernelMessenger. On effectue la mme opration que prcdemment en parsant le message. On rcupre alors la fentre dans laquelle le message doit tre afch, puis on le fait apparatre dans celle-ci.

F IG . 3.21 Rception dun message (Partie client)

- 25 -

III tude de conception UML du logiciel : Diagrammes dtats-transitions

3.8

Diagrammes dtats-transitions

Les diagrammes dtats transitions ont pour but de reprsenter les tats successifs dun objet en fonction des sollicitations externes et/ou des interactions avec dautres objets. Nous avons choisi de reprsenter les diffrents tats de lobjet Message. Celui-ci est au coeur de notre application. Nous avons choisi de le reprsenter en trois parties. * mission : le message est initialis puis cod en XML pour tre reconnu par le serveur * Partie Serveur/Client : le message est analys puis renvoy au serveur * Rception : le message est dcod. Il est sous la forme Message. Il est alors afch dans la fentre du destinataire

3.8.1

mission du message

F IG . 3.22 mission dun message

- 26 -

III tude de conception UML du logiciel : Diagrammes dtats-transitions

3.8.2

Serveur/Client

F IG . 3.23 Serveur/Client

3.8.3

Rception du message

F IG . 3.24 Rception du message

- 27 -

Chapitre 4

Conclusion
Ce projet ft trs intressant raliser. Il nous a permis de bien comprendre la dmarche suivre pour la ralisation de futurs grands projets. Il semble trs efcace de se tenir cette mthode car elle prend en compte la plupart des problmatiques rsoudre. Ce projet a t conu en parallle avec le dveloppement de notre application. Au dbut, les diagrammes classiques tels que ceux de squences ou de classes avaient dj t effectus pour bien tablir le design de lapplication. Nous avons vu que UML permet galement une tude dtaille grce par exemple aux diagrammes dtats-transitions et de collaborations qui sont trs bnques la comprhension du logiciel. Le langage UML est de plus trs visuel, ce qui est bien sr un atout lors de la conception de lapplication. Cependant, la version 1 du langage UML souffre de quelques lacunes au niveau du paralllisme et de la programmation rseau. UML2 semble combler ces petits manques et le futur aUML (a pour agent) permettra au langage dtre encore plus complet.

- 28 -

Table des gures

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 Business Model . . . . . . . . . . . . . Les diffrents cas dutilisation . . . . . Connexion BambooCh@t . . . . . . . Ajouter un contact . . . . . . . . . . . . Supprimer un contact . . . . . . . . . . Envoyer un message . . . . . . . . . . Connexion BambooCh@t (Client) . . Connexion BambooCh@t (Serveur) . Envoyer un message (Client) . . . . . . Envoyer un message (Serveur) . . . . . Rception dun message . . . . . . . . Ajout dun contact (Client) . . . . . . . Ajout dun contact (Serveur) . . . . . . Diagramme des classes Message . . . . Diagramme des classes : Requtes . . . Diagramme des classes : Rponse . . . Diagramme des classes : Analyse XML Paquets . . . . . . . . . . . . . . . . . Envoyer un message . . . . . . . . . . Rception dun message (Partie serveur) Rception dun message (Partie client) . mission dun message . . . . . . . . . Serveur/Client . . . . . . . . . . . . . . Rception du message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6 7 8 9 10 11 12 13 14 15 15 16 18 19 20 21 22 23 24 25 26 27 27

- 29 -