Bases de données et interfaces Génie logiciel Merlet benjamin Merlet-Billon Maryvonne Hueber Yann Jamin Guillaume Giraud Sandra Département Génie Biologique Professeurs responsables : Option BIMB Promotion 2013 Jean-Paul Rigault Anne-Marie Hugues
Introduction Un mini-projet PHP MySQL nous a été confié dans le but de favoriser le contact entre les élèves actuels du département Génie Biologique de l école Polytech Nice-Sophia et leurs prédécesseurs (ancien élèves). Afin de pérenniser toutes les données acquises sur les élèves au cours des années, ce projet a pour but de créer une interface web relié à base de données sur les élèves actuels et anciens de la filière biologique. Les contours et limites de ce projet sont détaillés dans le cahier des charges. De plus, chaque cas d utilisation identifié a été décortiqué et approfondie grâce à une analyse avec la language UML. De la conception de la base de données, au codage des pages web en PHP, en passant par la gestion de projet, tous les aspects nécessaires à l aboutissement d un projet de qualité ont été abordés. I- Cahier des charge Nous sommes chargés de créer un site web destiné principalement aux élèves et anciens élèves de Polytech Nice Sophia. Les responsables formations, et le responsable des relations industrielles pourront également intervenir sur ce site internet. Nous avons prévu que la gestion du site internet se ferait par les membres de l amicale des anciens élèves de Polytech Nice Sophia. Les élèves actuellement en formation à l école : - Auront un profil créé par leur responsable formation et contenant : - Leur nom, prénom - Leur promotion ainsi que l année de sortie correspondante (même future) - L historique de leur stage avec le nom de l entreprise, le tuteur et sa fonction et le nom du DRH -Pourront - Chercher les informations d un anciens élèves. - Accéder à des informations sur les entreprises enregistrées. - Postuler à une offre de stage déposée par un ancien élève.
Le responsable de formation pourra : - Créer le profil d un élève. - Changer le statut d un élève lorsqu il est diplômé. Il devra alors compléter son premier emploi si il le connait : avec l intitulé de l emploi, le nom de l entreprise et si possible le salaire brut annuel et le nom du DRH. - Chercher des informations dans la base de données afin de répondre à des statistiques sur le devenir des anciens élèves après leur sortie de l école et à un horizon de 2 ou 5 en terme de salaire et d emploi. Le responsable des relations industrielles pourra : - interroger la base de données afin de connaitre le nom des DRH des entreprises enregistrées (lorsqu il est renseigné) et leur envoyer un e-mail concernant la taxe d apprentissage. Les anciens élèves pourront : - Modifier les informations de leur profil : - Leur nom, prénom et email professionnel - Ajouter un nouvel emploi en renseignant le nom de l entreprise, l intitulé de l emploi et optionnellement le salaire brut annuel et le nom du DRH - Le domaine professionnel dans lequel il travaille -Consulter la date de validité de leur cotisation à l association des anciens élèves - Déposer une offre de stage ou d emploi à l attention des promotions en formation à Polytech Nice Sophia Les anciens élèves ne pourront pas modifier l année de l obtention de leur diplôme. Ils ont un droit d accès gratuit à ce site internet au cours des deux années suivants leur sortie de l école. Après cette date ils doivent obligatoirement payer leur cotisation à l association de l amicale des anciens. Si cette cotisation n est pas payée l ancien élève pourra uniquement modifier son profil.
L association des anciens élèves pourra : -Gérer les cotisations des anciens élèves en envoyant des mails de rappel aux anciens élèves n ayant pas payé leurs cotisations : les cotisations sont déclarées non valides via leur date de validité - Editer un annuaire au format PDF regroupé par promotion et par région qui pourra être vendu aux entreprises - Créer un évènement en renseignant la date, l intitulé et une description de l évènement - Promouvoir un évènement en envoyant un e-mail aux personnes enregistrées sur le site internet : élèves, anciens élèves, responsable formation et responsable des relations industrielles - Chercher un évènement dans la base de données dans le but de le modifier ou de le supprimer - Envoyer un e-mail aux anciens élèves dont le premier emploi n est pas renseigné II-Définition du produit Les cas d utilisation Dans l étape d analyse du projet, nous avons utilisé la langage UML afin d élaborer des diagrammes de cas d utilisation et des diagrammes d activités pour les différents acteurs. Cette étape va nous permettre de bien définir les limites de ce que pourront faire ou ne pas faire les différents utilisateurs. Les diagrammes de cas d utilisation sont des diagrammes UML permettant d avoir une vision globale du comportement fonctionnel de notre site web. Ces diagrammes identifient les fonctionnalités du système, les utilisateurs (appelés acteurs) et leurs interactions. Leurs objectifs sont d identifier les acteurs du systèmes, de fournir une vue d ensemble de ce a quoi le système pourra servir et permet ainsi de mieux cerner les secteurs nécessitant une interface homme-machine. Les diagrammes d activités sont également des diagrammes UML mais permettent le déroulement de différents évènements en fonction des états du système. Ce diagramme peut également être utilisé afin de décrire un processus de travail.
Diagramme des cas d utilisation de plus haut niveau Il existe 5 utilisateurs bien définis dans le cahier des charges. Il s agit des élèves, des anciens élèves, de l association des anciens élèves, du responsable des relations industrielles et du responsable formation. Chaque acteur va donc pouvoir gérer sa propre session une fois connectée sur le site web. Figure 1 : diagramme des cas d utilisation de plus haut niveau. Cas d utilisation commune à tous les utilisateurs Indifféremment de l utilisateur, l accession à la session de ce dernier se fera grâce son l authentification. Un mauvaise authentification d un utilisateur de le renverra sur la page d accueil du site web. A tout moment, l utilisateur peut se déconnecter. Figure 2 : diagramme de cas d utilisation d un utilisateur
Figure 3 : diagramme d activité de la gestion de la session d un utilisateur Cas d utilisation concernant les élèves Un élève actuel va principalement pouvoir consulter l annuaire des anciens élèves, consulter les évènements et consulter les offres de stages et d emplois. Il va également pouvoir modifier son profil (cas d utilisation ne figurant pas le diagramme des cas d utilisation car redondant avec les cas d utilisation développé dans la partie concernant les cas d utilisation des anciens élèves). Figure 4 : diagramme de cas d utilisation de gérer session élève
Figure 5 : diagramme d activité gérer session élève Scénario Cockburn fully-dressed du sous cas d utilisation «consulter annuaire des anciens élèves» - Acteur Primaire : élèves - Précondition : l élève est authentifié et a choisi «consulter l annuaire des ancien élèves» - Scénario typique : 1) Le système affiche des critères à remplir 2) L élève rempli les critères 3) Le système affiche la liste correspondante au choix 4) L élève clique sur un ancien élève qui l intéresse 5) Le système affiche plus en détails l ancien élève sélectionné 6) L élève enregistre sa page de réponse en format pdf 7) Le système enregistre la page de réponse en format pdf Variantes : 3.a La liste est vide goto 1 6.a L élève veut imprimer sa page de réponse goto 7 7.a Le système imprime la page de réponse
Données : annuaire des anciens élèves (Nom, Prénom, email personnel, date de naissance, numéro étudiant, adresse, option, année de diplôme, email professionnel) Cas d utilisation concernant le responsable de la formation Le responsable de formation va principalement pouvoir gérer les différentes promotions, gérer les stages des élèves, déposer des offres de stages et d emplois ainsi que calculer des statistiques. Figure 6 : diagramme de cas d utilisation de gérer session responsable de formation Figure 7: Diagramme d activité de la session du responsable de formation
Scénario Cockburn fully-dressed du sous cas d utilisation «gérer la promotion» - Acteur primaire : responsable de formation - Précondition : être connecté sur la session du responsable de formation et avoir choisi «gérer promotion» - Scénario typique : 1) Le système affiche la page permettant de gérer les promotions 2) Le responsable choisi d ajouter une nouvelle promotion 3) Le système affiche la page de création d une nouvelle promotion 4) Le responsable rentre les informations sur la promotion 5) Le système sauvegarde les informations Variantes : modifier des informations d une promotion existante 2a. Le responsable choisi une promotion existante 3a. Le système affiche les données de la promotion 4a. Le responsable modifie les informations de la promotion goto5 - Post condition : Le système affiche la page d accueil du responsable de formation Scénario Cockburn fully-dressed du sous cas d utilisation «gérer les stage» - Acteur primaire : responsable de formation - Précondition : être connecté sur la session du responsable de formation et avoir choisi «ajouter des informations sur un stage» - Scénario typique : 1) Le système affiche la liste des élèves 2) Le responsable sélectionne l élève pour lequel il veut ajouter un stage 3) Le responsable rentre les informations sur le stage 4) Le système enregistre ces données dans la base de données - Post condition : Le système affiche la page d accueil du responsable de formation Diagramme d activité de gérer session RRI
Le responsable des relations industrielles n a qu une seule utilisation du site web, l intérêt d un diagramme use case est donc très limité. Ici nous ne présentons que le diagramme d activité Le responsable des relations industrielles, après authentification va pouvoir accéder à la page des entreprises, ou il pourra y choisir quelques critères afin d afficher des informations (Nom de l entreprise, nom du DRH, domaine de l entreprise, chiffre d affaire de l entreprise, et informations pour contacter l entreprise) des entreprises qui l intéresse. Figure 8 : Diagramme d activité de consulter la liste des entreprises du RRI Scénario cockburn du cas d utilisation : consulter les entreprises Acteur primaire : Le RRI Précondition : Le RRI est authentifié Scénario typique : 1. Le système affiche la page personnelle du RRI
2. Le Système propose divers critères de choix pour l affichage des entreprises (Noms de l'entreprise, nom du DRH, CA, domaine) 3. Le système affiche les informations des entreprises selon les critères choisis par le RRI 4. Le RRI se déconnecte ou choisit de recommencer avec d'autres critères => Ceci termine le scénario Données : BDD entreprises : nomsentreprises, nomdrh, chiffreaffaire, domaineactivité, adressemail Variante : Il cherche plus d'informations sur une entreprise 4a) Le Système affiche la page détaillée d'une entreprise choisie par le RRI 4b) Le RRI revient à la liste des entreprises => Go to 4) Données : BDD Entreprises : nomsentreprises, nomdrh, chiffreaffaire, domaineactivité, adressemail, nompdg, description, adressesiègesocial, numtelephone
Gérer la Session Ancien Elèves : Diagramme des Use case de plus haut niveau Figure 9 : Diagramme des cas d utilisation anciens élèves Figure 10 : Diagramme d activité anciens élèves
Le diagramme des cas d utilisation de plus haut niveau présente les principales actions que peux effectuer l acteur Ancien Elève une fois qu il s est identifié sur le site. Pour chacun des trois sous cas d utilisation «Déposer Offres», «Mise à Jour» et «Accès info BBD», un scénario Fully Dresed de Cockburn est présenté ci-dessous. Scénario Cockburn Fully Dressed du cas d utilisation «Mise à Jour» Acteurs Principal : Ancien élève, tous les autres acteurs (mais ceux-ci, n auront pas accès à la variante 1.a) Acteurs Secondaire : Le Système Précondition : L ancien Elève choisi de modifier ses données. Accès à la Base de Données Scenario Typique : 1. L acteur modifie ses données personnelles et valide. Goto 2 2. Le système enregistre les nouvelles informations dans la base de données et confirme l écriture. Ceci termine le scénario. P0 Variantes : 1.a. L ancien élève modifie les données des étapes de son parcours professionnel et valide. Goto 2. 1.a.1. L ancien élève choisi d ajouter une étape à son parcours professionnel. Goto 3 1.b. L acteur quitte la page de modification de profil avant de valider. Ceci termine le scénario. P1 2.a. Le système reconnait que des informations obligatoires sont manquantes. Goto 1. 3. L ancien élève choisit l entreprise dans laquelle il a travaillé dans la liste. Goto 4. 3.a. L ancien élève rempli les informations sur une nouvelle entreprise et valide. Goto 5 4. L ancien élève rempli les informations nécessaires sur son emploi et valide. Goto 2. 5. Le système enregistre la nouvelle entreprise dans la base de données. Goto 3. 5.a. Le système reconnait que des informations obligatoires sont manquantes. Goto 3.a Post condition :
P0 : Les informations de la base de données ont été modifiées P1 : Les informations de la base de données n ont pas été modifiées Données nécessaires: Information utilisateurs Scénario Cockburn Fully Dressed du cas d utilisation «Déposé offre» (pas implémenté) Acteurs Principal : Ancien élève. Acteurs Secondaire : Le Système Précondition : L ancien Elève choisi de déposer une offre de stage. Accès à la Base de Données Scenario Typique : 1. L acteur les informations concernant l offre de stage /emploi données et valide. Goto 2 2. Le système enregistre les nouvelles informations dans la base de données et confirme l écriture. Ceci termine le scénario. P0 Variantes : 1.a. L acteur quitte la page de avant de valider. Ceci termine le scénario. P1 2.a. Le système reconnait que des informations obligatoires sont manquantes. Goto 1. Post condition : P0 : Les informations de la base de données ont été modifiées P1 : Les informations de la base de données n ont pas été modifiées Scénario Cockburn Fully Dressed du cas d utilisation «accés info BDD» Ce scénario est décrit dans les cas d utilisation de l acteur Elève
Gérer la Session Association : Diagramme des Use case de plus haut niveau Figure 11 : Diagramme des cas d utilisation de l association Figure 12 : Diagramme d activité de l association L association des anciens élèves intervient en tant qu administrateur du site internet. Ils ont des droits particuliers, spécifiques à leur statut. Un administrateur doit en premier lieu, comme tout utilisateur, s identifier avant d accéder à sa session. Un administrateur étant un ancien élève il possède un profil correspondant à ce statut.
Scénario Cockburn Fully Dressed du cas d utilisation «Gérer les cotisations» Acteurs Principal : Ancien élève. Acteurs Secondaire : Le Système Précondition : L administrateur s est authentifié et l authentification est réussie. Scénario Typique : 1. Le système affiche une page des cotisants non à jour 2. L administrateur sélectionne des cotisants 3. Le système propose d envoyer un e-mail aux cotisants sélectionnés 4. L administrateur rédige un mail 5. Le système envoie le mail, ceci termine le scénario Variante : 2. A : l'administrateur ne sélectionne aucun cotisants GOTO ceci termine le scénario Post condition : l e-mail a été envoyé Scénario Cockburn Fully Dressed du cas d utilisation «Promotion d un évènement» Acteurs Principal : Ancien élève. Acteurs Secondaire : Le Système Précondition : L administrateur s est authentifié et l authentification est réussie Scénario Typique : 1. Le système affiche une page proposant de créer un évènement 2. L administrateur choisit de remplir tous les champs de description 3. Le système enregistre les données 4. Le système stocke les données dans la base de données correspondante 5. Le système affiche un aperçu de l évènement 6. Le système propose d envoyer un e-mail pour promouvoir l évènement 7. L administrateur choisi d envoyer un e-mail 8. Le système envoie l e-mail, ceci termine le scénario Variante 1. A : le système affiche une page proposant de chercher un évènement existant
2. A : l administrateur sélectionne un évènement dans la liste GOTO 5 2. A : le système propose de supprimer l évènement 3. A : l administrateur choisi de supprimer l évènement 4. A : le système supprime l évènement de la base de donnée GOTO ceci termine le scénario Post condition : un e-mail est envoyé, un évènement est créé, un évènement est supprimé Diagramme de séquence 1. Authentification Lorsqu un utilisateur se connecte sur le site, il peut alors remplir les champs login et password. Ces informations sont alors envoyées vers un contrôleur qui va pouvoir orienter ses données vers le gestionnaire d authentification. Ce dernier va alors s assurer de l existence de l utilisateur dans la base de données et également vérifié son statut afin d afficher la page web en fonction. En cas d échec de l authentification, on message d erreur est afficher sur la page d accueil et l utilisateur peut à nouveau s authentifier.
Figure 11 : diagramme de séquence «authentification d un utilisateur» 2. Modification de profil Lorsqu un utilisateur souhaite modifier son profil, il va envoyer des informations, que la page PHP va traiter. Celle-ci va ensuite modifier la base de données, en mettant à jour les informations de l utilisateur, puis elle va mettre à jour les variables de session de la page courante, afin que les informations correspondent à celles que l utilisateur a mis à jour. Elle va générer une nouvelle page HTML avec les nouvelles informations qu elle renverra par la suite à l utilisateur.
Figure 12 : diagramme de séquence «modification du profil» 3. Recherche dans l annuaire Les élèves, les anciens élèves et l amicale des élèves vont pouvoir effectuer une recherche dans l annuaire des anciens. Il y a 3 types de formulaire à dispositions. Une recherche peut être effectuée directement avec le nom de l étudiant, avec le domaine professionnel ou encore avec l année de diplôme des anciens élèves.
Figure 13 : diagramme de séquence «recherche annuaire» III-Analyse Objet métier et base de données Diagramme de classe des objets métiers Toutes les informations concernant les utilisateurs sont dans la classe utilisateur, et ce indépendamment de leur statut. Ils peuvent être reliés à une entreprise via un stage ou un emploi. Les entreprises peuvent proposer des offres de stage ou d emploi, ainsi que les anciens élèves de la classe utilisateur.
Modèle logique de la base de donnée Le Modèle logique de la base de donnée est le suivant. Les liens entre les offres de stages/emploi, les stage, les emploi et l entreprise seront faites via une table supplémentaire, qui reliera les deux ID.
Collaboration des Classes Authentification L authentification est utilisée pour tous les use cases de plus haut niveau. Pour l authentification d un utilisateur, la page php utilisera la classe utilisateur de la base de données, afin de vérifier le login et le mot de passe, ainsi que pour récupérer le statut de l utilisateur, son nom et son prénom le cas échéant. Consulter les entreprises par le RRI Lorsque le RRI consultera les entreprises, la page correspondante utilisera la classe entreprise de la base de données, afin de pouvoir récupérer et afficher toute les informations des entreprises. La gestion des promotions par le responsable de formation Pour pouvoir consulter la liste des élèves de chaque promotion, la page correspondant utilise la classe utilisateur de la base de données : dans un premier temps afin de récupérer et afficher les différentes promotions référencées dans la base, puis, en fonction de la promotion choisie, pour pouvoir récupérer et afficher les noms et prénoms des élèves de cette promotion. La gestion des stages par le responsable de formation Lorsque le responsable de formation doit ajouter un stage, la page correspondante doit utiliser les classes utilisateur, stage et entreprise et entreprisestage lorsque l entreprise d accueil est mentionnée. La classe utilisateur permet de récupérer l identifiant de l élève, pour lequel le stage est ajouté, à partir de ces nom, prénom et promotion. Cet identifiant est utilisé pour la création du stage dans la table correspondante. Enfin, lorsque l entreprise d accueil est mentionnée, il y a une première étape qui consiste à vérifier si elle existe dans la classe
entreprise et de la créer si elle n y est pas. La seconde étape permet de faire la liaison entre le stage et l entreprise, grâce à la classe entreprisestage, en ajoutant les identifiants du stage et de l entreprise. IV-Conception-Réalisation Architecture logicielle Pour notre système informatique, nous n avons pas utilisé de classes PHP. Les informations de chaque utilisateur sont stockées dans la base de donnée, récupérées lors de l ouverture d une session, et sont conservée dans des variables de session, qui sont utilisables à tout moment. Ainsi nous n avons pas besoin de classes. Diagramme d excentricité
Maquette des pages PHP
Vue 3D de la page de modification du profil, cela permet de visualiser les divisions de la page et l imbrication des divisions. VI-Gestion du projet Diagramme de Gantt
Organisation du travail d équipe Au cours de ce projet, nous avons essayé autant que possible de nous partager les taches, afin de pouvoir avancer plus efficacement chacun de son côté. Nous avons découpé le projet en 5 parties : - Gestion de la session élève - Gestion de la session ancien élève - Gestion de la session du responsable de formation - Gestion de la session du responsable des relations industrielles - Gestion de la session de l Association Chaque partie a été associée à une personne du groupe, qui a élaboré sous ArgoUML les diagrammes des Use Cases et les diagrammes d activités correspondant. Ensuite, chacun a élaboré des scénarios cockburns, qui nous ont permis par la suite de mieux cerner les données dont nous aurons besoin. Le groupe a ensuite créé la base de données ainsi que le diagramme de classe, à partir duquel les pages PHP seront développées. Nous avons ensuite créé le diagramme d excentricité, puis nous nous sommes répartis les pages à coder de manière équitable entre chacun des 5 membres du groupe. Difficultés rencontrées Les difficultés rencontrées ont été principalement au niveau de la programmation des pages web. Nous avons essayé d utiliser un logiciel de gestion de version (git ou subversion), mais nous avons par la suite renoncé. En effet, nous avons eu du mal à utiliser git en plus d un serveur (nous avons essayé d utiliser le serveur de l école, sans succès), et de plus, certain problèmes de compatibilités entre nos ordinateurs ont rendu la tâche plus complexe. Nous avons donc décidé d utiliser Dropbox pour mettre en commun nos parties. Le logiciel est nettement moins adapté, mais incorpore tout de même une gestion basique des versions. Nous avons également rencontré divers problèmes au niveau de la programmation PHP, comme notamment la génération de PDF par le site web, qui nous ont empêchés de réaliser certains point de notre site web, et qui nous ont fait perdre du temps sur le projet.
Amélioration possibles Le code n étant pas complètement terminé et opérationnel, il convient d obtenir une version finale pleinement fonctionnelle avant d envisager plusieurs amélioration. Ensuite, nous aurions pu améliorer la sécurité au niveau de la base de donnée, notamment en donnant des droits de lectures sur certaines tables uniquement aux utilisateurs concernés, et d interdire toute lecture à un ancien élève dont la cotisation ne serait pas à jour. La sécurité aurait également pu être améliorée au niveau des mots de passe en utilisant dans la base de données une fonction de hachage : une telle fonction transforme le mot de passe en valeur hexadécimale. Par la suite il n est pas possible de retrouver le mot de passe à partir de cette valeur, cependant le schéma suivant est possible lorsque l utilisateur se connecte : le mot de passe rentré est passé à travers la fonction de hachage pour être comparé à la valeur enregistrée dans la base de donnée. Si les deux valeurs sont identiques l utilisateur est connecté. Si les valeurs sont différentes un message d erreur est affiché.