====== Etude de cas des uses cases au diagrammes de classes ====== L'objectif de ce TD est de vous aider à faire le point sur les diagrammes de classes et cas d'utilisation. Essayez d'avancer seul-e, puis regarder la page d'aide. Vérifiez que vous avez bien vu les différents éléments de l'étude de cas, complétez les pour aider vos camarades et vous même... ===== Etude de cas : un système de gestion de salles de jeux en ligne sur Internet ===== //D’après Denis Conan et Christian Bac, décembre 2010// Quatre rôles sont distingués dans le système : l’administrateur, l’organisateur d’un jeu, le joueur d’un jeu et un internaute. Dans la suite, nous ignorons la modélisation des fonctionnalités de l’administrateur et celles liées à un jeu donné. Nous ne nous intéressons qu’à la gestion des salles de jeux. L’étude de cas a été simplifiée. N’extrapolez pas sur l’énoncé! L’organisateur crée une salle de jeu pour jouer une (seule) partie d’un jeu donné et peut jouer dans sa salle de jeu. Les responsabilités d’un organisateur sont les suivantes : créer une salle de jeu en choisissant un nom pour la salle et un jeu, démarrer la partie de la salle de jeu lorsque le nombre de joueurs est atteint, ensuite fermer la salle de jeu. Bien sûr, un organisateur est donc également un joueur et il peut être un joueur dans une salle de jeu qu’il ne gère pas. Les joueurs, qui ont précédemment créé leur compte dans le système, se connectent, parcourent les salles de jeu ouvertes, choisissent une salle de jeu, jouent, et peuvent la quitter. Il n’est pas possible de rejoindre une salle de jeu si la partie est déjà démarrée, comme il n’est pas possible de quitter une partie démarrée. Un joueur peut afficher les points gagnés par lui et les autres joueurs, ainsi que l’historique des parties jouées (jeu, rôle et avatar choisis, nombre de points gagnés). Rien n’empêche une personne physique de créer plusieurs joueurs avec pour chacun un surnom différent; deux joueurs dans le système ne peuvent pas avoir le même surnom. Chaque joueur choisit son mot de passe lors de son inscription. Celui-ci doit respecter des contraintes telles que ne pas se trouver dans un dictionnaire, comporter un ou plusieurs chiffres et caractères spéciaux,.. Le parcours des salles peut se faire en naviguant ou en spécialisant le parcours par une recherche sur les jeux ou les joueurs. Un internaute peut visualiser les joueurs et les jeux présents dans le système. Il peut créer le compte d’un joueur. Nous supposons que le système propose une liste de jeux disponibles, c’est-à-dire nous ne nous intéressons pas à la création des jeux dans ce sujet. Un jeu est joué dans le cadre d’une salle de jeu et une salle de jeu permet de jouer à un seul jeu, et plus précisément, à une seule partie d’un jeu. Un nombre maximum de parties simultanées ainsi que le nombre de joueurs nécessaire est associé à chaque jeu. La définition du jeu comporte la description des rôles dans le jeu, et pour chaque rôle, la définition d’un certain nombre d’avatars proposés aux joueurs. Pour jouer dans une salle de jeu, un joueur rejoint la salle de jeu et demande à entrer dans le jeu. Si l’organisateur valide la demande, le joueur choisit un rôle et un avatar pour sa représentation dans cette salle de jeu. Le joueur représenté par un avatar joue alors dans une salle de jeu. Un joueur joue au plus un rôle dans une partie. À titre d’exemple, Julien se connecte, ouvre une nouvelle salle de jeu pour jouer aux échecs, et entre dans la salle du jeu. Il invite son amie Léa en lui téléphonant. Léa rejoint la salle de jeu ouverte par Julien et demande à entrer dans le jeu. Julien valide la demande de Léa. Il prend le rôle des « blancs » et Léa le rôle des « noirs ». Julien choisit comme avatar « Gandalf Le Blanc » et Léa choisit l’avatar « Sauron ». Julien démarre la partie. Le jeu, qui est extérieur à notre application, se déroule, jusqu’à ce que le jeu signale la partie comme finie et le nombre de points gagnés par chacun des joueurs. Tous les joueurs quittent la salle. En quittant une salle de jeux, le profil du joueur est visualisé : nombre de points marqués(//200pt//), parties réalisées, partie en cours ([]), etc.\\ Exemple de description d'une partie terminée : date(//2018-02-03T13:45:30//), jeux (//echec//), score//(50pt)//, durée(//1:22:07//, joueurs(//@lea, @Julien//), organisateurs(//@julien//), état (//"terminée"//).\\ Julien ferme la salle de jeu. ===== Cas d'utilisation ===== Un étudiant a commencé à modéliser les cas d'utilisation mais s'est arrêté avant d'avoir fini. Saurez-vous terminer & corriger le diagramme de cas d'utilisation suivant ? {{:2017_2018:s2:td:ucsalledejeux.png?300|}} ===== Diagrammes de classe ===== Un étudiant a commencé à modéliser le domaine mais s'est arrêté avant d'avoir fini encore plus vite que précédemment ! Saurez-vous compléter le diagramme de classes suivant ? {{:2017_2018:s2:td:classessalledejeux.png?700|}} Ne tenez pas compte de la notation en losange, elle exprime une composition que nous n'étudierons pas pour nous concentrer sur l'essentiel : savoir construire un diagramme de classe "Simple". De même nous n'étudierons pas les classes d'association, attributs dérivés, contraintes, dépendances, ... pour les mêmes raisons. Un diagramme juste est cohérent est préférable à un diagramme plein de notations faux. Cependant, si vous savez les utiliser "justement" alors vous pouvez les utiliser, vos enseignants les connaissent ! ==== Un peu d'aide ? ==== {{:2017_2018:s2:td:question-mark-2314115_960_720.jpg?200|}}[[2017_2018:s2:td:UC-Classes-help| De l'aide "collaborative"]] PAS DE RENDU si ce n'est en contribuant à la page d'aide !