Vous êtes sur la page 1sur 9

Achraf Dahmani / Lucas Parmentier

Etude du systme : Serveur de runions virtuelles.


Introduction :
Cette tude porte sur l'tude d'un systme permettant la participation des runions virtuelles. Ces dernires se droulent sur un serveur distant, permettant la participation depuis n'importe o. Pour le bon droulement de ces dernires, on mettra en place une hirarchie des utilisateurs : Sans avoir organis la runion ou sans avoir t nomm animateur par l'organisateur, un utilisateur ne pourra que consulter les messages et demander le droit de parole, et ne pourra envoyer de messages dans la runion que si ce droit lui est accord. Pour le bon fonctionnement du systme, on nommera un administrateur dont le rle sera de grer les comptes utiliss pour la connexion au serveur.

Cas d'utilisation.

Achraf Dahmani / Lucas Parmentier

On tudiera les actions que peuvent avoir les acteurs sur le systme depuis l'utilisateur avec les droits les plus forts (Administrateur) jusqu' l'utilisateur avec les droits les plus faibles (Utilisateur). Note pralable : -Ne sont pas renseigns les actions de connexion et de dconnexion au serveur : afin d'agir sur le systme Serveur il est indispensable de se connecter, connexion qui n'est pas permanente et qui implique donc une dconnexion. -De mme n'est pas indiqu le cas ou l'utilisateur dsire changer son mot de passe : On le considrera dans l'tude pralable comme faisant partie de la dconnexion. -Enfin, l'Administrateur ne peut, dans cette premire approche, avoir accs aux droits de l'utilisateur : pour simplifier notre approche, on le considrera seulement gestionnaire des comptes utilisateurs.

L'administrateur L'administrateur est gestionnaire des comptes utilisateurs, ses actions sont les suivantes : -Crer un compte utilisateur : Il peut crer un compte contenant les informations relatives l'utilisateur : nom, login et mot de passe initial (pour la connexion). -Nommer un Administrateur : Cette opration tend la cration d'un compte utilisateur, l'administrateur peut choisir ou non de nommer administrateur le compte venant d'tre cr. -Supprimer un utilisateur : L'administrateur peut choisir de supprimer un compte utilisateur, on considrera impossible pour ce dernier de supprimer le compte d'un autre administrateur.

L'organisateur L'organisateur est un utilisateur particulier : Il a accs toutes les actions que peut raliser ce dernier, que nous dtaillerons plus tard, et possde des droits propres ce statut. -Planifier une runion : En se nommant organisateur, un utilisateur peut choisir de planifier une runion en en renseignant les dates de dbut, de fin, une rapide description de la runion et le type de la runion (qui peut tre au choix standard, priv ou dmocratique). -Nommer un animateur : Cette action est obligatoire lors de la planification, elle est incluse cette action. L'organisateur peut toutefois se nommer lui mme animateur. -Nommer une liste d'utilisateur autoriss : Cette action tend la cration d'une runion, si l'organisateur dcide de crer une runion prive, il lui faudra saisir une liste d'utilisateurs autoriss participer cette runion. -Modifier les informations d'une runion : Il lui est enfin possible de modifier les informations d'une runion qu'il a auparavant planifi. L'animateur L'animateur est l'autre utilisateur particulier, il a pour but de grer le droulement de

Achraf Dahmani / Lucas Parmentier

la runion. Il est nomm par l'organisateur. Si ce dernier s'est lui mme nomm, il arroge les droits d' la fois l'organisateur et de l'animateur. -L'animateur peut ouvrir une runion : bien que soit prsente une date de dbut de runion, cette dernire ne peut commencer sans animateur, c'est donc lui qui va se charger la dbuter. A cette action sont incluses deux autres actions -Grer les demandes de parole : Dans le cas des deux premiers types de runions, standards et prives, c'est l'animateur qui va se charger de grer les demandes de paroles, sans quoi la runion ne peut avancer. Ouvrir une runion inclus donc de grer ces demandes de parole. Il n'y a pas d'animateur dans le cas d'une runion dmocratique. -Clturer la runion : De mme que pour l'ouverture de la runion, malgr la prsence d'une date de fin, il faut que l'animateur clture manuellement la runion. Cette action est incluse dans l'ouverture car on considrera que toute runion ouverture est fermer. L'utilisateur L'utilisateur est l'acteur de plus bas niveau. Il a pour rle de participer aux runions. -Consulter les informations : Tous les utilisateurs peuvent choisir de consulter les informations d'une runion, c'est dire les dates de dbut et de fin, la description de cette dernire ainsi que les participants autoriss si cette dernire est prive. -Participer une runion : Si une runion non prive est en cours, un utilisateur peut choisir de se connecter cette runion, il voit ainsi les messages qui ont ts envoys depuis le dbut de cette dernire. -Demander la parole : Cette action tend la participation, au cours de la runion, l'utilisateur qui le souhaite peut choisir de demander le droit de parole afin de participer la runion, c'est l'animateur qui lui accordera ou non. -Envoyer un message : Cette action est incluse dans le fait de demander la parole, on considrera qu'un utilisateur, une fois le droit de parole acquis, est oblig d'envoyer son message, selon les besoins du systme, on pourra considrer que la demande sera forcment associe au message que l'utilisateur souhaite envoyer. -Se nommer organisateur : Enfin, tout les utilisateurs peuvent choisir de planifier une runion, cette action lui permettra d'avoir accs aux droits d'un organisateur.

Scnario global d'utilisation.


/************************************************/

Achraf Dahmani / Lucas Parmentier

Diagramme de classe initial

Voici un diagramme de classe initial : il se focalise uniquement sur le processus de runion. On a deux classes, Organisateurs et Animateur, qui tendent la classe Utilisateur et qui possdent les mmes informations que ce dernier. Seul changement avec cette dernire sont les associations avec Runion ainsi que les mthodes, qui ne figurent ici pas dans les classes. On a une cardinalit de 1..1 pour l'organisateur vers la runions, et de 1..* dans l'autre sens : Un organisateur peut en effet organiser autant de runions qu'il le souhaite, mais une runion est organise par un seul utilisateur. On a aussi une cardinalit de 1..1 pour l'animateur vers la runions et la mme dans l'autre sens, une runion est anime par un seul utilisateur et un animateur n'anime qu'une seule runion ( la fois). De l'utilisateur vers la runion est prsent une cardinalit 0..* : si la runion est organise mais pas en cours, aucun utilisateur ne participe cette dernire. Enfin, on considre qu'un seul serveur est prsent. Si le systme le ncessite par la suite, on pourra ajouter un nombre quelconque de serveurs.

Achraf Dahmani / Lucas Parmentier

Diagrammes de squence Diagramme de squence de la connexion :

On prends comme situation initiale le cas ou le compte utilisateur n'existe pas. Si le rsultat de la connexion au serveur est ngatif, on reprend dans le diagramme peu avant la saisi du login+mdp.

Achraf Dahmani / Lucas Parmentier

Diagramme de squence de l'organisation de runion.

On dmarre dans le cas d'un utilisateur normal qui souhaite organiser une runion. La demande de droit d'organisateur et la rponse du serveur sont des actions synchrones, sans cela il aurait fallu passer l'utilisateur dans un tat de attente de la validation du serveur ; Il en est de mme pour la validation de la demande de runion. Une fois les informations saisie et la validation de la demande par le serveur l'utilisateur (qui cette priode est prsent organisateur), le serveur passera, pour cette runion uniquement, dans un tat d'attente du dbut de la runion. Pour des raisons de lisibilit on a prfr utiliser deux acteurs, utilisateur et gestionnaire. Il est noter qu'on aurait pu rajouter un troisime acteur, organisateur, qui aurait pris le relais des actions d'utilisateur une fois les droits d'organisation acquis.

Achraf Dahmani / Lucas Parmentier

Diagramme de squence : Ouverture de runion.

On dmarre au moment ou l'animateur require le dbut de runion. L'acteur runion est auparavant dans l'tat d'attente dans lequel fini le gestionnaire de runion dans le diagramme prcdent. Une fois la requte effectue, l'acteur Runion vrifie que la date de dbut qui a t renseigne par l'organisateur correspond la date de requte d'ouverture de runion. Si cette date ne correspond pas, le gestionnaire de runion se repasse dans l'tat d'attente de dbut : il attends qu'une requte d'ouverture concide avec la date de dbut. L'animateur se passe ensuite en attente des demandes de paroles. Le don des droits de parole est ici dirig vers la Runion et non vers l'Utilisateur, c'est en effet la Runion qui acceptera les message d'un utilisateur.

Achraf Dahmani / Lucas Parmentier

Diagrammes d'tat. Diagramme d'tat de la runion.

On a le diagramme d'tat de runion suivant. Il est noter qu'on part d'un tat ou la runion n'existe pas. De plus, on dissocie la runion finie de la runion ferme : c'est l'animateur de choisir s'il faut ou non clturer la runion. Cet tat permettrait de mettre en place un systme de pause de runion pour qu'il soit possible de la reprendre ultrieurement.

Achraf Dahmani / Lucas Parmentier

Diagramme d'tat utilisateur

Lutilisateur se connecte sur son compte et il a 2 choix , sois il demande le droit dtre organisateur comme a il peux organiser une runion, sois il consulte les information dune runion qui tais dj crer et quand il sera dans la runion il aura lhistorique des conversation dautres utilisateurs et il peux aussi demander le droit de parole, et quand il laura il peux parler.