Rapport de Conception Préliminaire MESSAGERIE

Transcription

1 Rapport de Conception Préliminaire MESSAGERIE Conception préliminaire du logiciel demandé en projet, illustré par les diagrammes des cas d utilisation, des classes du domaine et de séquence. Maxime SUARD, Jérôme MOUGEL, Ivan ORTEGA GARCIA, Romain DENIS 13/12/2009

2 I Introduction Dans le cadre du projet de conception d un logiciel d agenda/messagerie instantanée en ligne, notre groupe est chargé de concevoir la fonction messagerie instantanée. Le but de ce rapport est ici de finaliser la conception du logiciel en utilisant le langage graphique UML et donc de préparer la programmation de notre partie, à savoir la messagerie instantanée. L analyse comporte ainsi l étude des cas d utilisation, des classes du domaine et les diagrammes de séquences, très utile lors de la prochaine écriture du code. II Cas d utilisation L objectif de la messagerie instantanée étant en premier lieu de communiquer avec un ou plusieurs contacts, nous avons donc défini la fonction principale du système : communiquer. Il vient immédiatement le premier acteur du système : l utilisateur. Ainsi, avant de commencer une discussion, il convient à l utilisateur de choisir ses interlocuteurs, d où la fonction créer un groupe de discussion. Ensuite, les autres fonctions essentielles et évidentes sont les suivantes : envoyer message et recevoir message. De plus, il sera possible à l utilisateur de choisir de stocker ou non sa conversation lorsqu il fermera l onglet correspondant. Il sera de plus possible de stocker un message envoyé à un destinataire déconnecté pour le lui transféré lors de sa connexion. Ainsi, un nouvel acteur apparait : la base de données. L intérêt du logiciel est aussi l interaction entre la messagerie et l agenda. Il sera alors possible à partir de l agenda d envoyer via la messagerie une invitation à un événement. L agenda est donc un nouvel acteur du système. De plus, cette invitation pourra bien sûr être envoyée à un contact non connecté : elle sera stockée pour le lui transférer lors de sa connexion. Ainsi, un nouvel acteur apparait : la base de données. Enfin, pour discuter avec un ou plusieurs contact, l utilisateur, lors de la création de son groupe, doit pouvoir savoir lesquels d entre eux sont connectés ou non. Cette information de statut nous sera fournie par la gestion des comptes, nouvel acteur. 2

3 III Classes du domaine Tout d abord, nous avons décidé, lors de notre recherche des classes du domaine, de déterminer les classes de type boundary, control et entity. Ainsi, d un point de vue interface homme-machine (IHM), nous avons choisi de définir l interface de communication, sorte de page d accueil ou de démarrage de la messagerie, c est ici que l utilisateur pourra voir le statut de ses contacts et créer les groupes de conversation ; ainsi que l interface de conversation, fenêtre unique pour chaque conversation. Un autre type de classe boundary sera aussi mis en place. Lorsque l utilisateur envoie ou reçoit un message, celui-ci sera traité par la classe standard. En effet, un thread vérifiera régulièrement les entrées et les sorties. De plus, les objets dynamiques prépondérants dans ce système tels que les messages seront définis dans la classe message. Ces classes de type boundary sont bien évidemment en liées à des classes control. Nous en avons défini deux. La classe Gestion des contacts transmettra à Interface de communication les informations sur les contacts provenant de la classe entity nommée Mise à jour contacts. Cette dernière, sur commande de Gestion des contacts, mettra à jour 3

4 ses informations sur les contacts de l utilisateur en interrogeant la partie du système correspondante, Gestion des comptes. A chaque fois que l utilisateur créera un groupe de discussion via la classe Interface de communication, cette dernière sollicitera la seconde classe de type control de notre système Gestion des conversations. Celle-ci commandera la création d une nouvelle interface de conversation et d un objet nommé Conversation, d où la classe entity à son nom. Elle comportera toutes les informations caractérisant la conversation. Enfin, l entity appelée Stockage de conversation permettra de garder en mémoire le temps de la conversation les messages échangés puis, à la fin de celle-ci l objet correspondant sera soit supprimé si l utilisateur ne souhaite pas garder la conversation, soit envoyé à la Base de donnée dans le cas contraire. Voici donc le diagramme des classes du domaine, qui sera détaillé par la suite (il est à noté que le logiciel utilisé présente un problème d affichage des multiplicités ; celles-ci sont correctes sur le diagramme détaillé qui suit) : 4

5 Voici le diagramme des classes du domaine détaillé, comprenant les principaux attributs et méthodes des classes citées précédemment. Ces méthodes et attributs ont été déterminés lors de la rédaction des diagrammes des séquences correspondant aux différents cas d utilisation de notre projet. 5

6 IV Diagramme des séquences Voici les différents diagrammes de séquence correspondant à chaque cas d utilisation. Pour la réception d un message, on distingue plusieurs variations qui sont détaillées dans le digramme suivant : 6

7 Ensuite, le cas d utilisation Envoyer un message, nous avons le diagramme de séquence suivant : Afin de dialoguer avec des interlocuteurs, l utilisateur doit créer un groupe de conversation, ce qui est détaillé dans le diagramme qui suit : 7

8 Enfin, l utilisateur a la possibilité de garder en mémoire les conversations qu il entretient avec ses contacts. V Aperçu des Interfaces Homme-Machine envisagées Voilà les exemples des différentes interfaces Homme-Machine qui apparaîtront dans notre projet. On peut voir ici l interface de communication avec les contacts connectés et non connectés sur la gauche et sur la droite les onglets avec les différentes conversations pour lesquels une interface de conversation est créée. 8

9 Pour créer un groupe de discussion, l utilisateur devra sélectionner ses interlocuteurs sur une fenêtre pop-up : Voilà ce qui apparaîtra lorsque l utilisateur recevra un message différé : 9

10 Enfin, lorsque l utilisateur fermera l onglet de conversation, il aura la possibilité de sauvegarder les messages qu il vient d échanger : VI Remarques Malgré nos efforts afin de détailler au mieux les différentes classes ainsi que les éléments les caractérisant qui seront codées dans notre projet, nous sommes conscients qu un manque de précision est présent dans les diagrammes de séquence, notamment concernant les méthodes utilisées ainsi que leurs variables. Ce que l on remarque aussi sur le diagramme des classes du domaine. Il manque en particulier les méthodes dans la classe Standard permettant la création d une connexion UDP, d un port de réception et d émission. Il nous a paru en effet difficile de connaître très précisément les outils nécessaires au bon fonctionnement de notre système sans être dans la situation de codage. Nous avons cependant noté une grande amélioration de notre compréhension de la logique de conception préliminaire entre le premier rapport rendu et celui-ci, ce qui a éclairci notre vision du travail demandé. Enfin, nous avons remarqué, mais trop tard, qu un problème surviendrait sans doute lorsque qu un interlocuteur se déconnectera en cours de conversation et que nous n avons pas encore pris en compte la consultation des conversations stockées par l utilisateur. Ces problèmes devront donc être solutionnés lors de l écriture du code. 10