Système de réservation d`un centre de tennis
publicité
Système de réservation d’un centre de tennis BD50 – Conception de bases de données GL52 – Génie Logiciel Printemps 2005 Sommaire Sommaire ............................................................................................................................ 2 Préface................................................................................................................................. 4 1. Introduction ..................................................................................................................... 5 1.1 Buts et destinataires du document............................................................................. 5 1.2 Description du système ............................................................................................. 5 1.3 Définitions – Abréviation ......................................................................................... 5 1.4 Présentation générale du document .......................................................................... 6 2. Description générale ....................................................................................................... 7 2.1 Description générale des utilisateurs et de l’environnement .................................... 7 2.1.1 Les non-adhérents .......................................................................................... 7 2.1.2 Les adhérents ................................................................................................. 8 2.1.3 Les entraîneurs ............................................................................................... 8 2.1.4 Les administrateurs ........................................................................................ 9 2.1.5 Lexique général .............................................................................................. 9 2.1.6 Diagramme de contexte ............................................................................... 11 2.2 Modèle conceptuel fonctionnel ............................................................................... 12 2.3 Caractéristiques des utilisateurs .............................................................................. 12 2.4 Contraintes principales de développement ............................................................. 13 3. Besoins fonctionnels ..................................................................................................... 14 3.1 Cas d’utilisation ...................................................................................................... 14 3.2 Use Case “Réservation” .......................................................................................... 14 3.2.1 Cas d’utilisation ........................................................................................... 14 3.2.2 Description du cas d’utilisation ................................................................... 15 3.2.3 Digramme de séquence ................................................................................ 16 3.3 Use Case “ Tournoi ” .............................................................................................. 18 3.3.1 Cas d’utilisation ........................................................................................... 18 3.3.2 Description du cas d’utilisation ................................................................... 18 3.3.3 Digramme de séquence ................................................................................ 19 3.4 Use Case “Administrateur” ..................................................................................... 21 3.4.1 Cas d’utilisation ........................................................................................... 21 3.4.2 Description du cas d’utilisation ................................................................... 22 3.4.3 Digramme de séquence ................................................................................ 23 4. Spécifications des structures de données ...................................................................... 24 4.1 Diagramme de classes ............................................................................................. 24 4.2 Description du diagramme de classes ..................................................................... 25 5. Spécifications des interfaces externes ........................................................................... 26 5.1 Interface Matériel/Logiciel ..................................................................................... 26 5.2 Interface Logiciel/Logiciel...................................................................................... 26 5.3 Interface Homme/Logiciel ...................................................................................... 27 5.3.1 ‘Charte graphique’ ....................................................................................... 27 5.3.2 Ecran d’interface et spécifications des menus ............................................. 28 6. Besoins en performance ................................................................................................ 33 2 7. Contraintes de développement ...................................................................................... 34 7.1 Sécurité ................................................................................................................... 34 7.2 Standard .................................................................................................................. 34 7.2.1 UML............................................................................................................. 35 7.2.2 Méthode Merise ........................................................................................... 36 7.2.3 SQL .............................................................................................................. 36 7.2.4 PL/SQL ........................................................................................................ 36 8. Conception et réalisation : partie BD50 ........................................................................ 37 8.1 Modèle conceptuel de données ............................................................................... 37 8.1.1 Modèle Global ............................................................................................. 37 8.1.2 MCD - Sous-modèle Inscriptions ................................................................ 39 8.1.3 MCD - Sous-modèle Réservation ................................................................ 40 8.1.4 MCD - Sous-modèle Planning ..................................................................... 41 8.2 Modèle logique de données .................................................................................... 42 8.2.1 MLD - Sous-modèle Inscription .................................................................. 42 8.2.2 MLD - Sous-modèle Réservation ................................................................ 43 8.2.3 MLD - Sous-modèle Planning ..................................................................... 44 8.3 Description des tables ............................................................................................. 45 8.4 Modèle logique de données optimisé ...................................................................... 46 8.4.1 Suppression de tables ne comportant qu’une seule clef............................... 46 8.4.2 Redondance calculée .................................................................................... 46 8.4.3 Fusion de tables............................................................................................ 47 8.4.4 Choix d’héritages ......................................................................................... 47 8.5 Les packages ........................................................................................................... 51 8.6 Exemple de script .................................................................................................... 53 9. Conclusion .................................................................................................................... 57 10. Références ................................................................................................................... 58 9.1 Bibliographie........................................................................................................... 58 9.2 Webographie ........................................................................................................... 58 3 Préface Au cours de notre cursus à l’Université de Technologie de Belfort – Montbéliard, nous avons la possibilité de suivre des Unités de Valeur (UV) nous mettant face à des projets à réaliser en intégralité. Les UV couplées de BD50, Conception de bases de données, et GL52, Génie Logiciel, nous permettent de gérer le projet – Système de réservation d’un centre de tennis, sujet qui nous a été attribué. Le présent rapport est la mise en forme de du cahier de spécifications dédié à l’UV de GL52. 4 1. Introduction 1.1 Buts et destinataires du document Le but de ce document est de formaliser les exigences du client afin de pouvoir répondre au mieux à ses attentes. En tant que base de travail, le dossier de spécification décrit les différentes fonctionnalités que l’application devra assurer. 1.2 Description du système Nous avons pour sujet le développement d’un système de réservation d’un centre de tennis en ligne. Il devra permettre aux différents utilisateurs de connaître ce que propose le centre de tennis mais également de réserver du matériel et autres services. Ce système devra être capable d’assurer une consultation conviviale et sécurisée, accessible à tout utilisateur connecté à Internet. Pour rendre le système plus efficient, un système de connexion au site sera proposé aux membres du club, permettant d’accéder à de nouvelles fonctionnalités. Pour le centre de tennis, le système permettra de mieux suivre le déroulement des réservations à l’aide de certaines fonctionnalités aidant à la gestion. D’un point de vue technique, un SGBDR de type Oracle contiendra les informations de l’agence immobilière et le site sera développé à l’aide du langage PL/SQL. 1.3 Définitions – Abréviation Nous faisons un abus de langage puisque dans tout le prochain document nous considérons qu’un joueur peut être un adhèrent, un non adhèrent et un entraîneur ; mais aussi que les membres sont les adhérents, les entraîneurs. Pour toute le reste de la description du projet, nous allons utiliser les termes propres aux joueurs de tennis ; ceux-ci étant entrés dans le langage courant, nous ne les définirons pas. SGBDR : Système de Gestion de Base de Données 5 1.4 Présentation générale du document Le document de spécification présente d’abord le sujet d’un point de vue général et le décrit en langage naturel. Puis il décrit précisément toutes les fonctionnalités du système. Ensuite, le système est replacé dans ses contraintes environnementales et techniques. 6 2. Description générale 2.1 Description générale des utilisateurs et de l’environnement L'application client/serveur d’un système de réservation d’un centre de tennis permet une interaction via Internet entre un centre de tennis physique et ses membres. Le système de réservation d’un centre de tennis doit permettre à des clients de louer un court de tennis sur des plages horaires, de prendre des cours avec des entraîneurs, de louer du matériel de jeu et de réserver le ‘club house’ en cas de manifestation. Les utilisateurs de cette application sont donc de plusieurs types, tels que définis dans les quatre parties suivantes. De plus, un lexique général est décrit après les utilisateurs. Ces quatre types d'utilisateurs représentent les agents de notre système. Les interactions entre ces acteurs et le système sont décrites dans le diagramme de contexte figurant à la page 11. 2.1.1 Les non-adhérents Tout d'abord, il y a les non-adhérents qui sont des utilisateurs quelconques, naviguant sur Internet, et qui vont visiter le site du centre de tennis. Un non-adhèrent peut ainsi consulter les offres que le centre de tennis a mis en ligne, se renseigner sur l'agence physique (coordonnées, emplacement, etc.). Il peut louer un court, du matériel (sous caution). La réservation ne pourra se faire que lorsque la réservation précédente, si il y a, est passée. Les autres possibilités du centre de tennis ne seront accessibles qu’après inscription au centre de tennis. De plus, pour effectuer la réservation en ligne, le numéro de carte bancaire est demandé, stocké en mémoire mais la carte ne sera pas débitée ; le paiement se fera directement chez la secrétaire le jour de ladite réservation. Dans la mesure où les non adhérents sont membres de la FFT, ils peuvent en entrant leur numéro de membre, s’inscrire aux tournois de la FFT. De plus, ils peuvent par le site faire une demande de réservation du ‘Club House’. Ces fonctionnalités sont destinées à toute personne ayant accès au site, et consistent essentiellement en la réservation d’un court de tennis. Fonctionnalités requises : Consulter les informations mises en ligne Réserver un court, du matériel S’inscrire à un tournoi Faire une demande de réservation du ‘Club House' 7 2.1.2 Les adhérents Une fois cotisant, l’utilisateur est alors considéré comme un adhèrent du centre de tennis, et possède un login et un mot de passe afin de s'identifier sur le site. Il pourra alors accéder à son espace personnel. Cet espace comporte plusieurs rubriques : ainsi, il peut accéder et modifier les données (données personnelles, cotisations, type d’inscription, palmarès…) le concernant, accéder à leur historique, réserver un terrain, du matériel (sous caution), s’inscrire à un cours ou tournoi. Il ne peut réserver qu’une plage horaire dans une même journée, mais peut en réserver une autre seulement si la précédente est expirée. Ces fonctionnalités sont destinées aux utilisateurs étant au préalable adhérents. L'acteur adhèrent est considéré comme une extension de l'acteur non-adhèrent et peut donc également utiliser les fonctionnalités de celui-ci. Fonctionnalités requises : Se loguer/déloguer Modifier ses données personnelles Consulter ses cotisations, type d’inscription, palmarès Réserver un cours 2.1.3 Les entraîneurs Au sein du centre de tennis, les entraîneurs utiliseront le système afin de gérer leurs cours en priorité. Ils posséderont un login et un mot de passe pour s'identifier, de la même façon que les adhérents. L’entraîneur gère, en plus, de son cours (planning annuel, plages horaires, type de cours, niveau…) et il réserve du matériel pour leur cours. Il peut proposer, via le système, des tournois et stages. Partie du site possédant un accès limité, ce système est destiné aux entraîneurs employés par le centre de tennis. L'acteur entraîneur est considéré, par ailleurs, comme une extension de l'acteur adhèrent et peut donc également utiliser les fonctionnalités de celuici. Fonctionnalités requises : Gérer son planning (annuel, hebdomadaire) Gérer les cours Réserver des terrains et matériels pour les cours Proposer stage et/ou tournoi 8 2.1.4 Les administrateurs Il existe également un autre type d'utilisateur de l'application : c'est l'administrateur, dans notre cas, nous considérons que ce sont des administrateurs : le directeur et la ou les secrétaires du club. L’administrateur peut créer, modifier, supprimer des adhérents ou entraîneurs (avec login, mot de passe, etc.), et peut consulter tous les options proposées sur le site. De plus, il peut gérer (ajouter, modifier, supprimer) le matériel, les terrains, les cours, les stages, les tournois. Extension de tous nos agents, l’administrateur permet de contrôler le travail des différents entraîneurs et d’obtenir des informations de gestion. Fonctionnalités requises : Créer, modifier, supprimer des agents Créer, modifier, supprimer des événements (stage, tournoi, cours) Gérer le matériel et terrains Consulter tous les événements, les réservations et autres demandes. 2.1.5 Lexique général Nous allons maintenant décrire les différents termes et leurs propriétés que nous allons utiliser tout au long de ce projet. Le matériel Le matériel à louer se divise en deux groupes : les balles et les raquettes, qui peuvent être dans un état libre, réservé, utilisé. Les raquettes ont un état supplémentaire qui est la maintenance. Le prêt se fait en quantité limitée et sous caution en précisant la date, l’heure et la durée de prêt. La caution et le paiement (pour les non-adhérents) pour le matériel se fait directement lors du retrait de celui-ci. Le ‘Club House’ Le ‘club house’ peut être l’objet d’une demande de réservation par les utilisateurs du système. Demande qui devra être argumentée et envoyée (par le système) par email à la secrétaire. Cette dernière réservera alors le ‘Club House’, mais uniquement après validation du responsable du centre de tennis. 9 Les cours Les cours peuvent être en commun ou peuvent être également des cours particuliers. Ils sont réservés aux membres du club. Dans le cadre des institutions, la demande de réservation se fait par l’envoi d’un email via le système à la secrétaire qui valide (ou non) la réservation dans le système. Un planning annuel des cours est mis en place en fonction de la disponibilité des entraîneurs ; les terrains utilisés pour ces cours ne sont donc pas disponibles à ces plages horaires fixes. Pour les adhérents dont le quota est dépassé ou dont l’inscription ne comprend pas les cours, la réservation se fait comme d’habitude mais une facture sera envoyée mensuellement. Les stages Les stages sont des événements exceptionnels, organisés par les entraîneurs et la direction du club. Ils sont accessibles pour tous, adhérents ou non. Les dates et les quotas des stages sont affichés en ligne, mais l’inscription et le paiement se font via la secrétaire, pour des raisons de sûreté au niveau bancaire pour le club. Les tournois Les tournois peuvent être de 2 types : internes au club et en association avec la Fédération Française de Tennis. Pour s’inscrire et participer aux tournois internes, il faut être membre du club. Les tournois sont organisés suivant la catégorie d’ages, quel que soit le niveau de l’adhérent. En ce qui concerne les tournois de la FFT, il faut bien sur être adhérent à la FFT (donc pas nécessairement adhérent au club). Les inscriptions ne peuvent se faire que si la catégorie d’ages et de niveau sont respectés. Les inscriptions Il en existe trois types : le premier donne un accès gratuit à l’adhèrent aux terrains et au prêt de matériel (ce dernier est toutefois sous caution). La deuxième formule englobe le premier type mais donne un accès, suivant le quota voulu, aux cours dispensés par le club. Une troisième formule permet d’ajouter à l’inscription la cotisation de la FFT. Les inscriptions et réservations peuvent être annulées ou modifiées. Le paiement se fait lors des inscriptions et réservations ; le centre de tennis laisse la possibilité à la personne de modifier ses vœux avec remboursement de la somme si l’annulation ou la modification se fait un jour avant l’échéance. 10 2.1.6 Diagramme de contexte Nous allons présenter le diagramme de contexte général pour présenter les actions générales liant les différents types d’utilisateurs présentés ci-dessus et le système. Nous considérons que les options mises à disposition pour chaque utilisateur se transmet à l’utilisateur dont les capacités lui sont supérieures. Figure №1 : Diagramme de contexte du système de réservation d’un centre de tennis. 11 2.2 Modèle conceptuel fonctionnel On peut découper le système de ‘réservation d’un centre de tennis’ en groupements de fonctionnalités, réunies dans une catégorie spécifique. Ainsi, on peut considérer que l'on a trois grands groupes de fonctionnalités : - les fonctions de gestion des réservations - les fonctions de gestion des membres - les fonctions internes au système. Figure №2 : Modèle Conceptuel Fonctionnel Il existe également des fonctionnalités diverses qui ne peuvent entrer dans ces catégories, mais dont l'extrême simplicité nous permet de ne pas les spécifier de manière complexe (par exemple : s'identifier sur le site, se déconnecter, etc…) 2.3 Caractéristiques des utilisateurs Les utilisateurs de l'application Client/Serveur du Système de réservation du centre de tennis sont les acteurs définis dans l'environnement et le contexte d'utilisation de l'application. Ceux-ci sont de quatre types : - Utilisateur non enregistré : c'est l'utilisateur standard qui navigue sur Internet, ou non-adhèrent. - Utilisateur enregistré : c'est l'internaute qui connaît le site et est inscrit au club de tennis. A partir de ce moment il peut réaliser des opérations spécifiques au membre et gérer ainsi son propre compte. - Utilisateur de la partie administrative : c'est un utilisateur enregistré qui possède des droits sur la partie administrative du site, qui lui permettent de modifier le contenu du site (dans notre cas, la création de cours). Cet utilisateur est un entraîneur du centre de tennis. - Utilisateur administrateur du site : c'est le directeur du centre de tennis ou sa secrétaire. Il peut créer des nouveaux comptes pour les agents, il peut ajouter des terrains, … 12 L'ensemble de ces utilisateurs ne maîtrise pas forcément l'outil informatique. On considère que les utilisateurs sont non informaticiens. Les adhérents et non-adhérents auront accès au site de la manière la plus simple et ergonomique possible. Pour les employés du centre de tennis, il faut également réaliser une application compréhensible sans avoir de connaissances autres que basiques en informatique. Dans le cas des employés, une formation sur le logiciel est à prévoir, mais même sans celle-ci, le logiciel doit être suffisamment facile à prendre en main, afin qu'il puisse être utilisé de manière simple et intuitive. En ce qui concerne la fréquence d'utilisation, les non-adhérents seront des utilisateurs très occasionnels. Les adhérents, eux, sont susceptibles d'utiliser l'application de manière plus ou moins fréquente (réservation hebdomadaire d’un terrain, ou joueur journalier). Pour les entraîneurs, cette application est conçue pour une utilisation journalière du logiciel, qui leur permet de gérer l'ensemble de leur planning et des cours qu’ils dispensent. C'est un outil de gestion à part entière qui permet d'obtenir beaucoup d'informations, très importantes pour les entraîneurs ou pour l’administrateur. La connexion à l'application se fera donc au minimum une par jour. 2.4 Contraintes principales de développement L’application utilisera une base de données Oracle (v.9i) et le langage utilisé pour réaliser les pages du site sera PL/SQL, couplé à HTML. Le document de Spécification fera l’objet d’une réunion de validation avec monsieur Koukam. Le MCD de la base de données devra être validé avec monsieur Fischer. 13 3. Besoins fonctionnels 3.1 Cas d’utilisation Les cas d'utilisation décrits ci-après représentent les fonctionnalités principales de notre système. En effet, certaines fonctionnalités ne nécessitent pas de représentation ou d'être détaillées, de par leur simplicité. Ainsi, on ne décrit pas les cas d'utilisation tels que : - se connecter / se déconnecter - envoyer un message (mail ou formulaire) … Nous avons donc regroupé les principaux cas d'utilisation suivant les différents utilisateurs du système, définis ci-après. 3.2 Use Case “Réservation” 3.2.1 Cas d’utilisation ‘utilise’ ‘utilise’ Figure №3 : Use Case « Réservation » 14 3.2.2 Description du cas d’utilisation Effectuer une réservation Acteurs déclencheurs : Non-adhèrent, Adhèrent, Entraîneurs ou Administrateur Entrées : Critères de réservations choisis par l’acteur déclencheur Sorties : Validation ou échec de la réservation Le demandeur remplit un formulaire lui permettant de préciser les critères de sa réservation. Il valide ensuite sa requête et le site lui renvoie si sa demande est validée ou non. Valider une réservation Acteurs déclencheurs : Administrateur Entrées : modifications : données d’une réservation. Sorties : la réservation est validée, modifiée voir même supprimée Dans le cas où un utilisateur envoie une requête spécifique sur une demande de réservation spéciale, il doit en faire part à l’administrateur. C’est lui qui s’occupe de la validation, modification ou suppression de cette demande. 15 3.2.3 Digramme de séquence Le diagramme de séquence représente l’enchaînement logique des fonctionnalités, propres à la réservation, que peuvent effectuer l’adhèrent et l’administrateur et leurs interactions avec le système. Nous avons deux types de réservations qui découlent de cet Use Case : la réservation de matériel, de terrain (ou de cours pour les adhérents) qui ne nécessite pas de validation spécifique de l’administrateur et la réservation de cours (pour les organismes) ou du Club House, qui elle, a besoin de l’aval de l’administrateur pour être effective. Nous présenterons un diagramme de séquence pour chaque cas. Figure №4 : Diagramme de séquence « Réservation », cas avec seule interaction du système 16 Figure №5 : Diagramme de séquence « Réservation », cas avec validation de l’administrateur 17 3.3 Use Case “ Tournoi ” 3.3.1 Cas d’utilisation ‘utilise’ Figure №6 : Use Case « Tournoi » 3.3.2 Description du cas d’utilisation Effectuer une Inscription Acteurs déclencheurs : Non-adhèrent, Adhèrent, Entraîneurs Entrées : Critères d’inscription au tournoi sélectionné Sorties : Validation ou échec de l’inscription Le demandeur remplit un formulaire lui permettant de préciser les informations nécessaires à son inscription. Il valide ensuite sa requête et le site lui renvoie si sa demande est validée ou non. 18 3.3.3 Digramme de séquence Le diagramme de séquence représente l’enchaînement logique des fonctionnalités, propres aux tournois, que peut effectuer l’adhèrent et son interaction avec le système. Nous avons deux types d’inscription aux tournois qui découlent de cet Use Case : il existe deux types de tournois les tournois de la FFT (Fédération Française de Tennis) et les tournois internes au Club. Pour participer à ces derniers, il faut être membre du Club tandis que pour les tournois FFT si l’utilisateur possède un numéro FFT, il peut s’inscrire à ce type de tournoi. Nous présenterons un diagramme de séquence pour chaque cas. Figure №7 : Diagramme de Séquence « Tournoi », cas des tournois internes 19 Figure №8 : Diagramme de séquence « Tournoi », cas des tournois FFT 20 3.4 Use Case “Administrateur” 3.4.1 Cas d’utilisation Figure №9 : Use Case « Administrateur » 21 3.4.2 Description du cas d’utilisation Créer une manifestation Acteurs déclencheurs : Administrateur Entrées : Proposition de manifestation par l’entraîneur ou l’acteur déclencheur Sorties : Création ou non de la manifestation avec insertion dans le planning L’entraîneur (ou l’administrateur dans certain cas) remplit un formulaire lui permettant de préciser les critères de sa proposition de manifestation. Il valide ensuite sa requête et celle-ci est envoyée à l’administrateur qui valide ou non la proposition avant de la créer dans le système. Nous ne détaillerons pas le cas où l’administrateur modifie ou supprime la manifestation puisque le principe est le même. Ajout de matériel Acteurs déclencheurs : Administrateur Entrées : Sorties : ajout dans le système de matériel supplémentaire. (matériel ou terrain) L’administrateur remplit un formulaire ajoutant du matériel (voir un terrain). Il valide ensuite sa requête pour que le système l’affiche pour les utilisateurs. Modifier du matériel Acteurs déclencheurs : Administrateur Entrées : Changement d’état du matériel Sorties : Modification de l’état, voir même suppression, du matériel. Dans le cas où le matériel est détérioré (ou réparé), l’administrateur modifie le formulaire du matériel concerné. Il valide ensuite sa requête pour que le système mette à jour les données. Ajout d’un membre Acteurs déclencheurs : Administrateur Entrées : Sorties : ajout dans le système d’un membre supplémentaire. L’administrateur remplit un formulaire ajoutant un membre. Il valide ensuite sa requête pour que le nouveau membre puisse désormais se connecter. Modification/Suppression d’un membre Acteurs déclencheurs : Administrateur Entrées : Modification des données concernant un membre Sorties : Modification des données, voir même suppression, du membre. Dans le cas où un utilisateur demande à l’administrateur de modifier ses données, l’administrateur modifie le formulaire de la personne concernée. Par ailleurs, si un membre quitte le club, l’administrateur supprime ce membre de la base. Dans les deux cas, la requête est validée pour être ensuite envoyée au système qui mettra la base de données à jour. 22 3.4.3 Digramme de séquence Le diagramme de séquence représente l’enchaînement logique des fonctionnalités, propres à la réservation, que peuvent effectuer l’adhèrent et l’administrateur et leurs interactions avec le système. De ce Use Case, nous pouvons déduire la consultation et la modification des données personnelles des membres qui se déroulent de la même manière, et que nous détaillerons pas. Figure №10 : Diagramme de séquence « Administration » 23 4. Spécifications des structures de données 4.1 Diagramme de classes Le diagramme de classe va nous permettre de représenter les différentes classes, de manière à faire apparaître pour chaque classe ses attributs et ses opérations spécifiques. Chaque classe sera davantage décrite par la suite. Figure №11 : Diagramme des classes du système de réservation du centre de tennis 24 4.2 Description du diagramme de classes INSCRIPTION : Classe dans laquelle se trouve toutes les informations concernant l’inscription. INSTITUTION : Classe dans laquelle se trouve toutes les informations concernant une institution. PERSONNE : Classe dans laquelle se trouve toutes les informations de base d’un utilisateur, soit informations d’un non adhèrent. ADHERENT : Classe qui hérite des informations de la classe Personne, contenant des informations supplémentaires propres à l’adhèrent. ENTRAINEUR : Classe qui hérite des informations de la classe Adhèrent et contenant des informations supplémentaires propres à l’entraîneur. ADMINISTRATEUR : Classe qui hérite des informations de la classe Personne et qui contient des actions propres à l’administrateur. RESERVATION : Classe qui contient les informations nécessaires à une réservation. MANIFESTATION : Classe qui contient les informations concernant une manifestation dont le type de la manifestation. MATCH : Classe qui contient les informations sur les différents matchs d’une manifestation. La classe Manifestation, si le type est tournoi, est composée de matchs. COURT : Classe qui contient les informations des différents terrains du centre de tennis. MATERIEL : Classe qui contient les quantités et les types de matériel que propose le club de tennis. CLUB HOUSE : Classe qui contient les informations spécifiques au Club House. 25 5. Spécifications des interfaces externes 5.1 Interface Matériel/Logiciel Configuration minimale : Pentium 500 Carte graphique 12 Mo 4 Go de disque dur (installer Oracle au complet : 3 Go) Configuration optimale : PC de bureau, Processeur Athlon XP 2600+ Carte graphique 64 MO + de 10 Go de disque dur Caractéristiques des interfaces système / dispositifs particuliers : Notre système ne nécessite aucune adaptation particulière et peut être utilisé sans ajouter de dispositif particulier. Il fonctionne avec un ordinateur de type bureautique classique. 5.2 Interface Logiciel/Logiciel Le système de Réservation d’un centre de tennis utilise les ressources du SGBDR Oracle 9i. Nous utilisons le langage PL/SQL pour l'accès à la base de données (utilisation du logiciel SQL+, ProcedureBuilder, Jdevelopper, etc.) Protocole d'échange et type de liaison : L'application nécessite d'être stockée sur un serveur d'applications, relié à d'autres ordinateurs par l'intermédiaire d'un réseau. Nous considérons que ce réseau est câblé avec des liaisons de type RJ45, et que l'on utilise comme seul protocole le protocole TCP/IP. Enfin, l'utilisation d'un navigateur permet l'utilisation de notre logiciel : le plus répandu est Internet Explorer (version 5.5 ou +). Nous avons utilisé ce browser pour les tests de notre application. 26 5.3 Interface Homme/Logiciel 5.3.1 ‘Charte graphique’ Nous avons décidé de créer un site suivant les couleurs qui rappellent aux utilisateurs les couleurs du tennis. Pour toutes les pages, nous avons insérer une image fixe d’un joueur de tennis, que nous avons récupérer sur internet. Et pour tout ce qui concerne les objets que nous avons codés nous avons utilisé des couleurs ‘orange’ et ‘jaune’. Pour ce qui est de la typographie, nous avons choisi d’utiliser la police « Times new roman» ; c’est une police qui facilite la lisibilité des textes à l’écran et est très utilisée pour tous les textes à lire sur écran. Toute notre mise en page est gérée par la feuille de style Charte graphique CT_style.css. Figure №12 : Gabarit, présentant la schématisation des pages du site, définissant les emplacements principaux ainsi que leur type de contenu 27 5.3.2 Ecran d’interface et spécifications des menus Nous avons défini les interfaces principales qui seront utilisées pour notre application. Nous avons travaillé sur l'ergonomie et la lisibilité des pages, de manière à ce que l'utilisation du logiciel soit agréable et simplifiée pour nos utilisateurs. Ainsi, les deux premières interfaces (Figures 13 et 14) présentent les pages auxquelles accède l'utilisateur qui ne fait pas partie de la base de données du centre de tennis. Les pages suivantes (Figures 15 à 20) représentent des fonctionnalités supplémentaires accessibles pour les joueurs et membres du centre de tennis ou des administrateurs du site. Ces interfaces sont présentées dans les pages suivantes. Figure №13 : Accueil 28 Figure №14 : Inscription d’un nouvel utilisateur Figure №15 : Authentification des utilisateurs 29 Figure №16 : Liste des réservations disponibles Figure №17 : Liste des cours disponibles 30 Figure №18 : Description détaillée d’un stage Figure №19 : Liste des entraîneurs 31 Figure №20 : Gestion du matériel 32 6. Besoins en performance Notre application étant de type site Internet, nous n'avons pas beaucoup d'informations à fournir sur les besoins en performance du projet. En effet, la plupart des caractéristiques influant sur les performances reposent sur le serveur où sera hébergé l'application qui, la plupart du temps, est soumis aux caractéristiques de l'hébergeur. Nous allons donc simplement pouvoir influer sur le nombre de nos fichiers et leur taille, ainsi que dans le développement en lui-même. En effet, les performances de l'application sont intimement liées à la qualité de la conception et de l'implémentation. Au niveau conceptuel, l'importance de la structure de la base de données se vérifie lors de son utilisation : plus elle est conçue avec soin, plus elle sera facile d'accès et les appels réalisés vers la base de données seront optimisés de manière à ne pas surcharger la connexion à la base. Ainsi, l'optimisation des tables de la base de données et la mise en place d'index judicieusement choisis permettent une optimisation des performances. Au niveau implémentation, le développement du code de manière intelligente permet d'obtenir des performances meilleures. La manière dont les fichiers seront répartis dans l'arborescence, avec un contenu réfléchi pour être optimisé, influe également sur les performances. Ci-après nous vous présentons l'arborescence de notre application. Figure №21 : Arborescences des données 33 7. Contraintes de développement 7.1 Sécurité Afin d'être utilisé en entreprise ou dans un organisme où des informations circulent, une application doit prendre en compte le problème de la sécurité. En effet, il est nécessaire de protéger l'accès aux données qui peuvent être considérées comme sensibles. Au sein de notre projet, nous avons étudié cet aspect "sécurité" uniquement au niveau de l'application, puisque la sécurité "physique" (au niveau du réseau ou des utilisateurs par exemple) ne nous incombe pas. La mise en place de mots de passe permet de séparer les personnes qui peuvent avoir accès à l'application et les autres personnes. Parmi les personnes qui possèderont un mot de passe permettant d'avoir accès à l'application, nous avons instauré des "types" d'utilisateurs, qui n'auront pas accès aux mêmes fonctionnalités : les utilisateurs ‘adhérent’ n'auront par exemple pas accès aux commandes permettant de modifier la base de données des manifestations par exemple. Ainsi, nous mettons en place un contrôle des accès aux données par une restriction sur l'utilisation de certaines commandes pour certains utilisateurs. 7.2 Standard Lors du développement de notre projet, nous avons utilisé des méthodes, outils et langages de développement, qui sont le plus souvent assujettis à des standards. En ce qui concerne les technologies du Web, le W3C (World Wide Web Consortium) fixe les normes à respecter : il nous concerne puisque nous utilisons des pages codées en HTML. Nous avons décrit ci-après différentes méthodes (UML, Merise) et différents langages (PL/SQL) utilisés dans notre projet. 34 7.2.1 UML UML (Unified Modeling Language) est une notation permettant de modéliser un problème de façon standard. Ce langage est né de la fusion de plusieurs méthodes existant auparavant, et est devenu désormais la référence en terme de modélisation objet. - Les années 1970 - Les premières méthodes d'analyse apparaissent. - Les années 1980 - Annonce l'approche systémique (modélisation des données et modélisation des traitements : Merise, Axial, IE...). - Entre 1990-1995 - Emergence d'une multitude de méthodes objet : Booch, ClasseRelation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE... - 1995 marquera les premiers consensus - OMT (James Rumbaugh) / OOD (Grady Booch) / OOSE (Ivar Jacobson). - Les années 1995-1997 - Unification et normalisation des méthodes : naissance d'UML. A partir de 1997, UML est devenue une norme de l'OMG, ce qui lui a permis de s'imposer en tant que méthode de développement objet et être reconnue et utilisée par de nombreuses entreprises. La modélisation consiste à créer une représentation simplifiée d'un problème: le modèle. Elle comporte deux composantes: - L'analyse, c'est-à-dire l'étude du problème - La conception, soit la mise au point d'une solution au problème Le modèle constitue ainsi une représentation possible du système pour un point de vue donné. UML fournit une panoplie d'outils permettant de représenter l'ensemble des éléments du monde objet (classes, objets, ...) ainsi que les liens qui les relie. Etant donné qu'une seule représentation est trop subjective, UML permet de représenter diverses projections d'une même représentation grâce aux vues. Une vue est constituée d'un ou plusieurs diagrammes. On distingue deux types de vues: - Les vues statiques, c'est-à-dire représentant le système physiquement o diagrammes d'objets o diagrammes de classes o diagrammes de cas d'utilisation o diagrammes de composants o diagrammes de déploiement - Les vues dynamiques, montrant le fonctionnement du système o diagrammes de séquence o diagrammes de collaboration o diagrammes d'états-transitions o diagrammes d'activités 35 7.2.2 Méthode Merise MERISE est une méthode de conception, de développement et de réalisation de projets informatiques qui date de 1978-1979. Le but de cette méthode est d'arriver à concevoir un système d'information. La méthode MERISE est basée sur la séparation des données et des traitements à effectuer en plusieurs modèles conceptuels et physiques. La séparation des données et des traitements assure une longévité au modèle. En effet, l'agencement des données n'a pas à être souvent remanié, tandis que les traitements le sont plus fréquemment. 7.2.3 SQL SQL (Structured Query Language) est un langage de définition de données, de manipulation de données, et de contrôle de données. C'est surtout un langage d'interrogation de bases de données. Très répandu, il permet de manipuler assez facilement les bases de données relationnelles. Il permet d'ajouter des données, de les supprimer, parfois par tables entières, de les sélectionner (Select) dans des tables (From), selon toutes sortes de critères (Order by, Group by, Where...). 7.2.4 PL/SQL Le langage PL/SQL est un langage L4G (langage de quatrième génération), fournissant une interface procédurale au SGBD Oracle. Le langage PL/SQL intègre parfaitement le langage SQL en lui apportant une dimension procédurale. En effet, le langage SQL est un langage déclaratif non procédural permettant d'exprimer des requêtes dans un langage relativement simple. En contrepartie il n'intègre aucune structure de contrôle permettant par exemple d'exécuter une boucle itérative. Ainsi le langage PL/SQL permet de manipuler de façon complexe les données contenues dans une base Oracle en transmettant un bloc de programmation au SGBD au lieu d'envoyer une requête SQL. De cette façon les traitements sont directement réalisés par le système de gestion de bases de données. Cela a pour effet notamment de réduire le nombre d'échanges à travers le réseau et donc d'optimiser les performances des applications 36 8. Conception et réalisation : partie BD50 8.1 Modèle conceptuel de données Nous avons utilisé la méthode Merise pour représenter le système de réservation d’un centre de tennis, au travers d'un Modèle Conceptuel de Données ou MCD. Il définit de manière globale les données et fonctions que nous allons utiliser au sein de la base de données qui sera associée à notre logiciel. Le MCD correspondant à notre application peut se diviser en sous-modèles, spécifiques à différentes parties de ce projet. Ainsi, nous avons découpé le MCD en trois sous-modèles : - Inscriptions - Réservation - Planning 8.1.1 Modèle Global Le modèle global, réalisé à partir des sous-modèles précédemment cités, représente le modèle Entité-Association du projet ‘Système de réservation d’un centre de tennis’. C'est un modèle qui utilise les méthodes de conception de la méthode Merise. Il définit l'ensemble des données et leurs fonctions au travers de ses entités (noms) qui sont reliées par des associations (verbes). Il nous permet également de définir à un niveau conceptuel les types des données que nous allons utiliser dans notre base de données (nombres, chaînes de caractère, etc.) De par sa complexité, nous allons vous présenter les modèles dans le reste du dossier dans notre découpage en trois sous-modèles. 37 Figure № 22 : MCD ‘Système de réservation d’un centre de tennis’ 38 8.1.2 MCD - Sous-modèle Inscriptions Figure № 23 : MCD ‘Gestion des Inscriptions’ 39 8.1.3 MCD - Sous-modèle Réservation Figure № 24 : MCD ‘Gestion des Réservations’ 40 8.1.4 MCD - Sous-modèle Planning Figure № 25: MCD ‘Gestion du Planning’ 41 8.2 Modèle logique de données Toujours en utilisant la méthode Merise, nous avons défini le Modèle Logique de Données ou MLD qui correspond au MCD précédemment décrit. Aussi appelé Modèle Relationnel, celui-ci est beaucoup plus proche de la structure de la base de données que nous allons utiliser lors de l'implémentation. En effet, il définit les tables qui vont constituer la base de données. De même pour plus de lisibilité, nous avons choisi de représenté le MLR en 3 sousmodèles. 8.2.1 MLD - Sous-modèle Inscription Figure № 26 : MLD ‘Gestion des Inscriptions’ 42 8.2.2 MLD - Sous-modèle Réservation Figure № 27 : MLD ‘Gestion des Réservations’ 43 8.2.3 MLD - Sous-modèle Planning Figure № 28 : MLD ‘Gestion du Planning’ 44 8.3 Description des tables Table PERSONNE INSTITUTION INSCRIPTION SOUSCRIREP SOUSCRIREI PAIEMENTMENSUELPPAIEMENTMENSUELI CLUBHOUSE COURT MATERIEL RESERVATION MANIFESTATION OCCUPER UTILISE CONCERNEMATERIEL INSCRITI - INSCRITP ANIMER MATCH EQUIPEDOUBLE Description Données renseignant un joueur ou un entraîneur Données renseignant une institution(école, association, club,…) Rassemble l’ensemble des forfaits disponibles avec leur propriétés Tables permettant de lier un joueur ou une institution adhérente à un certain forfait, tout en gardant l’historique des souscriptions Tables permettant de savoir si un joueur ou une institution adhérente a payé son forfait pour un certain mois, en précisant le montant des extras (manifestations, heures hors quotas, etc…) Données du Club House(cette table ne contiendra donc qu’une occurrence) Rassemble les courts de tennis et leur propriétés (nom, surface, …) Données des matériels disponibles et leur quantité (balles et raquettes au minimum) Permet de sauvegarder les réservations de court de tennis par un joueur ou une institution, ainsi que leurs propriétés (date, heure, …) Données de toutes les manifestations enregistrées (cours, stages ou tournois) avec leur propriétés nécessaires (nom, organisateur, date, ..) Permet de donner une représentation globale de toutes les occupations de court de tennis avec leur cause, que ce soit pour une simple réservation par un joueur ou une institution, ou pour une utilisation par une manifestation. Précise les matériels empruntés en même temps qu’une réservation (raquettes et balles), ainsi que leur quantité Précise les matériels utilisés par une manifestation (raquettes et balles), ainsi que leur quantité Tables permettant d’inscrire un joueur ou une institution(nombre de personne à préciser) à une manifestation Donne les entraîneurs affectés à une manifestation, autres que l’organisateur Ensemble des matchs organisés au cours d’un tournois, ainsi que leur propriétés(participants,…) et leurs résultats Ensemble des équipes composées par 2 joueurs 45 8.4 Modèle logique de données optimisé Le MLD tel qu'il est représenté sur la page précédente n'est pas le diagramme abouti que l'on va utiliser pour générer la base de données. En effet, il nécessite une optimisation qui lui permet d'être plus proche de la réalité et plus adapté à la réelle utilisation de la base de données : on veut obtenir une performance optimale en terme de temps de réponse de la base de données. Le MLD optimisé ainsi obtenu est plus généralement appelé Modèle Physique optimisé. On traite ainsi la redondance d'information pour mettre en place une facilité de développement et limiter les jointures lors des requêtes sur la base, afin de diminuer le temps de réponse. On modifie également le MLD afin de diminuer le nombre de tables, en supprimant ou fusionnant des tables existantes, tout cela en conservant les informations et la plus grande partie de la normalisation que nous a apporté la conception. 8.4.1 Suppression de tables ne comportant qu’une seule clef Cette suppression concerne notamment les tables de Date et de Mois. Par exemple dans la gestion des paiements mensuels des adhérents (sous modèle Gestion des Inscriptions), l’entité MOIS sera supprimée, et en conséquence son index primaire associée, alors que l’entité de paiement verra sa clef étrangère ANNEEMOIS transformée en clef primaire simple. Ce procédé aura permis de gagner en nombre de tables et en nombre d’index primaires, donc en performance. 8.4.2 Redondance calculée Les courts de tennis sont occupés soit par des manifestations soit par des réservations. 2 tables sont donc utilisées afin sauvegarder ces occupations (sous-modèle Gestion des Réservations) : la table RESERVATION et la table OCCUPE(pour les manifestations). Nous avons préféré rassembler toutes les réservations de courts, que ce soit par des réservations normales ou par des manifestations, dans une seule et unique table OCCUPER, ce qui amène à une redondance vis à vis de la table RESERVATION, mais ce qui permet de simplifier les requêtes quant à la gestion des courts inoccupés ou non. En conséquence, cette table disposera des 3 clefs étrangères permettant d’identifier l’occupant du court, puisque celui-ci peut être de différents types. 46 8.4.3 Fusion de tables Dans la gestion du planning, on peut s’apercevoir de la gestion assez lourde des matchs. Afin de la simplifier, nous avons choisi de fusionner plusieurs tables pour éviter les jointures, et ainsi gagner en nombre de tables. Premièrement, on doit remarquer que beaucoup de jointures dans la gestion des matchs sont formées en réalité de cardinalités (2,2) : ainsi, on peut éviter une table de jointure en ajoutent tout simplement deux clefs étrangères ; c’est le cas de l’EQUIPEDOUBLE composée de deux joueurs, d’un MATCH composé de deux joueurs ou de deux équipes. On exécutera la même opération sur la table des SET, puisqu’un match ne contient au maximum que 5 sets. Dans ce cas, les colonnes SET1 à SET5 seront des chaînes de caractères ou seront stockées leur résultat. Mais ceci implique une plus grande difficulté à connaître le vainqueur d’un match (il suffisait auparavant de compter de nombre d’occurrences de Sets gagnés), c’est pourquoi nous avons choisi d’ajouter une redondance à notre table MATCH : il s’agit du joueur ou de l’équipe vainqueur. Au final, nous avons une réduction de 6 tables, et donc une gestion beaucoup plus simplifiée des matchs. 8.4.4 Choix d’héritages Un entraîneur ayant droit au même traitement qu’un joueur, avec seulement des possibilités et droits supplémentaires, nous avons choisis de remonter les propriétés d’un entraîneur dans la table PERSONNE afin d’économiser des jointures superflues, ce qui a pour effet d’augmenter le nombre de champs d’une personne : les propriétés propres à un entraîneur permettront alors d’identifier ce type. 47 Figure № 29 : MLD optimisé ‘Gestion des Inscriptions’ 48 Figure № 30 : MLD optimisé ‘Gestion des Réservations’ 49 Figure № 31 : MLD optimisé ‘Gestion du Planning’ 50 8.5 Les packages Nous avons décidé de mettre nos procédures et fonctions dans 11 packages. CT_Authentification Contient toutes procédures et fonctions permettant à l’utilisateur de se connecter avec un login et mot de passe CT_Insertions Contient toutes les procédures permettant les traitements d’insertion CT_Insertions_Form Contient toutes les procédures de l’interface d’insertions CT_Updates Contient toutes les procédures permettant les traitements de mise à jour CT_Updates_Form Contient toutes les procédures de l’interface de mise à jour CT_Delete Contient toutes les procédures permettant les traitements de suppression de données CT_Gestion Contient toutes les procédures et fonctions permettant la gestion du système CT_Edit Contient toutes les procédures et fonctions permettant l’édition du système CT_Joueur Contient toutes les procédures et fonctions propres à la gestion des joueurs CT_Institutions Contient toutes les procédures et fonctions propres à la gestion des institutions CT_Court Contient toutes les procédures et fonctions propres à la gestion des courts Lors de la connexion, le package CT_authentification est lancé et permet pendant toute la navigation des utilisateurs connectés une sécurité sur le passage des données. Toutes nos pages s’enchaînent plus ou moins de la manière suivante : Appel d’une page du type : CT_Gestion.gest_(nom de table) Cette procédure appelle différents types d’autres procédures suivant l’action demandée par l’utilisateur : - CT_Insertion_Form.CT_insert_(nom table) - CT_Updates_Form.CT_UPDF_(nom table) - CT_EDIT.ED_(nom table) - CT_DELETE_(nom table) 51 Les deux premières procédures, quant à elles appellent elles aussi d’autre procédure du type : - CT_Insertion.CT_ins_(nom table) - CT_Updates.CT_UPD_(nom table) Nous avons tenté au maximum de séparer les packages d’IHM et ceux contenant les requêtes en relation avec la base de données. Nous n’avons pas eu toutefois le temps d’enlever tous les liens vers notre page .css que nous avons insérés ; de plus, nous avons eu l’idée de créer un nouveau package ‘curseur’ pour y insérer tous nos curseurs dont l’appel aurait été fait dynamiquement mais nous n’avons pas eu non plus le temps de coder cette partie. Figure № 32 : Architecture des packages 52 8.6 Exemple de script Dans cette partie, nous avons inséré un imprime-écran de la partie de code qui est décrite ci-après. 53 54 55 56 9. Conclusion La mise en place de ce système de réservation d’un centre de tennis en ligne a été une expérience très enrichissante pour nous. Cependant, nous avons passé beaucoup de temps, peut-être même trop, sur la conception d’une maquette : comment réaliser ce site d’un point de vue technique mais aussi qu’elles étaient les fonctionnalités que nous souhaitions y voir. C’est pourquoi, nous n’avons pas eu le temps de mener à bien la partie de codage ; ainsi nous avons dû mettre des priorités sur les parties que nous voulions aborder telles que la réservation en elle-même ou l’authentification par exemple contrairement à la partie esthétique que nous avons mise un peu de coté. 57 10. Références 9.1 Bibliographie Cours de Base de données – UV BD50 – M. Christian Fischer Université de Technologie de Belfort-Montbéliard – Semestre de Printemps 2005 Cours de Génie Logiciel – UV GL52 – M. Abder Koukam Université de Technologie de Belfort-Montbéliard – Semestre de Printemps 2005 9.2 Webographie http://www.oracle.com Site du SGBDR Oracle 58
