République Algérienne Démocratique et Populaire Ministère de l’Enseignement Supérieur et de la Recherche Scientifique Université Abdelhamid Mehri Constantine 2 Faculté des Nouvelles Technologies de l’Information et la Communication Département des Technologies des Logiciels et Systèmes d’Information Projet de fin d’étude pour l’obtention du diplôme de Licence en Informatique Option : Génie Logiciel SYSTÈME DE GESTION DES ABSENCES POUR UNIVERSITÉ INTELLIGENTE Réalisé par : Ouail Derghal Aymen Belala Dirigé par : Dr. Zakaria Lakhdara Remerciments Nous tenons à remercier toutes les personnes qui ont contribué au succès de ce projet et qui nous ont aidé lors de la rédaction de ce mémoire. Nous voudrions remercier dans un premier temps l’encadreur de ce projet M. Zakaria Lakhdara, Professeur Adjoint à l’université de Constantine 2, pour sa patience, sa disponibilité et ses conseils pertinents, qui ont contribué à enrichir ce projet. Nous remercions également l’équipe pédagogique de la faculté des nouvelles technologies de l’information et de communication et les résponsables de la formation Génie Logiciel, pour leurs efforts durant les six semestres. Nous tenons à témoigner toute notre reconnaissance à nos parents et nos proches, pour leur soutien constant et leurs encouragements. Merci Table des matières 1 Introduction générale 1.1 Introduction générale . . . . . . . . . . . . . . . 1.2 Description du projet . . . . . . . . . . . . . . . 1.3 Problématique . . . . . . . . . . . . . . . . . . 1.4 Solution proposée . . . . . . . . . . . . . . . . . 1.5 Le génie logiciel . . . . . . . . . . . . . . . . . . 1.5.1 Les approches du génie logiciel . . . . . 1.6 Le langage de modélisation unifié - UML . . . . 1.6.1 Définition et historique . . . . . . . . . 1.6.2 L’importance de modélisation . . . . . . 1.6.3 Les usages d’UML . . . . . . . . . . . . 1.6.4 Les diagrammes d’UML . . . . . . . . . 1.7 Le processus unifié . . . . . . . . . . . . . . . . 1.7.1 Définition . . . . . . . . . . . . . . . . . 1.7.2 Les caractéristiques du processus unifié 1.7.3 L’objectif du processus unifié . . . . . . 1.7.4 L’architecture UP . . . . . . . . . . . . 1.8 Les activités du processus unifié . . . . . . . . . 1.8.1 Expression des besoins . . . . . . . . . . 1.8.2 Analyse . . . . . . . . . . . . . . . . . . 1.8.3 Conception . . . . . . . . . . . . . . . . 1.8.4 Implémentation . . . . . . . . . . . . . . 1.8.5 Test . . . . . . . . . . . . . . . . . . . . 1.9 Les phases du processus unifié . . . . . . . . . . 1.9.1 Analyse des besoins . . . . . . . . . . . 1.9.2 Élaboration . . . . . . . . . . . . . . . . 1.9.3 Construction . . . . . . . . . . . . . . . 1.9.4 Transition . . . . . . . . . . . . . . . . . 1.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9 9 10 10 11 11 13 13 14 14 15 17 17 17 18 19 19 19 20 20 20 20 20 20 20 20 21 21 2 Analyse des besoins 2.1 Introduction . . . . . . . . . . . . . . . . 2.2 Expression des besoins . . . . . . . . . . 2.2.1 Cahier des charges . . . . . . . . 2.2.2 Identification des acteurs . . . . 2.2.3 Diagramme de contexte statique 2.2.4 Documentation des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 22 22 22 24 25 26 3 . . . . . . . . . . . . . . . . . . . . . . . . 2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 27 28 29 29 29 33 41 49 3 Conception 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 3.2 Diagramme de classe conceptuel . . . . . . . . . . 3.2.1 Identification et documentation des classes 3.2.2 Diagramme de classes . . . . . . . . . . . . 3.3 Schéma et diagramme de la base de données : . . . 3.3.1 Schéma de la base de données . . . . . . . . 3.3.2 Diagramme de la base de données . . . . . 3.4 Scénario d’exécution . . . . . . . . . . . . . . . . . 3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 50 50 50 64 66 66 68 70 77 4 Implémentation 4.1 Introduction . . . . . . . . . . . . . . . . . . . . 4.2 Environnement de développement . . . . . . . . 4.3 Base de données . . . . . . . . . . . . . . . . . 4.4 Application Web . . . . . . . . . . . . . . . . . 4.4.1 Language de programmation . . . . . . 4.4.2 La structure du projet . . . . . . . . . . 4.4.3 Captures de l’application Web . . . . . 4.5 Appareil de prise de présences . . . . . . . . . . 4.5.1 Raspberry PI . . . . . . . . . . . . . . . 4.5.2 La technologie de radio-identification . . 4.5.3 Conception de l’appareil . . . . . . . . . 4.5.4 Communication avec la base de données 4.6 Le projet API REST . . . . . . . . . . . . . . . 4.7 Le projet de l’appareil de prise de présences . . 4.8 Application mobile . . . . . . . . . . . . . . . . 4.8.1 Android . . . . . . . . . . . . . . . . . . 4.8.2 L’historique des versions d’Android . . . 4.8.3 Environnement de développement . . . 4.8.4 Communication avec la base de données 4.8.5 La structure du projet . . . . . . . . . . 4.8.6 Captures de l’application mobile . . . . 4.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 78 78 79 81 82 84 86 87 87 94 94 96 97 98 99 99 100 101 102 103 105 108 2.4 2.5 Identification des besoins . . . . . . . . . . . 2.3.1 Les besoins fonctionnels du projet . . 2.3.2 Les besoins non-fonctionnels du projet Spécification des besoins . . . . . . . . . . . . 2.4.1 Identification des cas d’utilisation . . . 2.4.2 Diagrammes de cas d’utilisation . . . 2.4.3 Documentation des cas d’utilisation . 2.4.4 Diagrammes de séquence système . . . Conclusion . . . . . . . . . . . . . . . . . . . 5 Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Table des figures 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Les approches du génie logiciel. . . . . . . . . StarUML version 3.1.1 . . . . . . . . . . . . . Diagramme de classes du NodeJS v0.8.12 . . Importance de la modélisation . . . . . . . . Les usages du langage de modélisation unifié Développement par itérations successives . . . Le cycle de vie du processus unifié . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12 13 14 15 18 19 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 Le diagramme de contexte statique. . . . . . . . . . . . . . . . . . Diagramme de cas d’utilisation A1-Administrateur. . . . . . . . . . Le diagramme de cas d’utilisation A2-Enseignant. . . . . . . . . . Diagramme de cas d’utilisation A3-Responsable de formation. . . . Diagramme de cas d’utilisation A4-Chef département. . . . . . . . Diagramme de cas d’utilisation A5-Étudiant. . . . . . . . . . . . . Diagramme de séquence système Consulter le relevé des absences. . Diagramme de séquence système Consulter les statistiques. . . . . . Diagramme de séquence système Faire l’appel. . . . . . . . . . . . . Diagramme de séquence système Faire une réclamation. . . . . . . Diagramme de séquence système Gérer les justifications (Accepter). Diagramme de séquence système Justifier une absence. . . . . . . . Diagramme de séquence système Ajouter un étudiant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 30 31 31 32 32 42 43 44 45 46 47 48 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 Diagramme Diagramme Diagramme Diagramme Diagramme Diagramme Diagramme Diagramme Diagramme 4.1 4.2 4.3 4.4 4.5 4.6 Universal Database Manager . . . Interaction avec la base de données L’architecture client-serveur. . . . . JetBrains IntellijIDEA . . . . . . . Dépendances du projet Maven . . Modèle . . . . . . . . . . . . . . . . de classes . . . . . . . . . . . . . . . . de la base de données . . . . . . . . . . d’activité Ajouter un étudiant . . . . . d’activité Consulter le relevé d’absence d’activité Consulter les statistiques . . d’activité Faire l’appel . . . . . . . . . d’activité Faire une réclamation . . . . d’activité Gérer les justifications . . . d’activité Justifier une absence . . . . . . . . . . . . . . . . 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 69 70 71 72 73 74 75 76 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 80 81 82 83 84 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 Vue . . . . . . . . . . . . . . . . . . . . . . . . . Contrôleur . . . . . . . . . . . . . . . . . . . . . . Structure du projet de l’application Web . . . . . Capture 1 de l’application Web . . . . . . . . . . Raspberry PI Zero . . . . . . . . . . . . . . . . . Dimensions de la Raspberry PI . . . . . . . . . . Raspberry PI détaillée . . . . . . . . . . . . . . . Connexion SSH à une Raspberry Pi . . . . . . . General Purpose Input/Output interface (GPIO) Module RFID-RC522 . . . . . . . . . . . . . . . . Schéma de branchement . . . . . . . . . . . . . . Données en format JSON . . . . . . . . . . . . . Architecture de communication . . . . . . . . . . Éditeur de code Vim . . . . . . . . . . . . . . . . Architecture logicielle de l’Android . . . . . . . . Android Studio version 4.0.1 . . . . . . . . . . . Les dépendances de l’application mobile . . . . . La structure du projet Android . . . . . . . . . . Capture 1 de l’application mobile . . . . . . . . . Capture 2 de l’application mobile . . . . . . . . . Capture 3 de l’application mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 85 85 86 87 89 90 93 93 94 95 96 97 99 101 102 103 104 105 106 107 Liste des tableaux 1.1 1.2 Les trois aspects d’un système d’information . . . . . . . . . . . . . . . . . . . . . Regroupement des diagrammes par aspect . . . . . . . . . . . . . . . . . . . . . . 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 15 17 La fiche descriptive de l’acteur administrateur . . . . . . . . . . . . . . La fiche descriptive de l’acteur enseignant . . . . . . . . . . . . . . . . La fiche descriptive de l’acteur responsable de formation . . . . . . . . La fiche descriptive de l’acteur chef département . . . . . . . . . . . . La fiche descriptive de l’acteur étudiant . . . . . . . . . . . . . . . . . Fiche descriptive du cas d’utilisation Faire l’appel . . . . . . . . . . Fiche descriptive du cas d’utilisation Faire une réclamation . . . . Fiche descriptive du cas d’utilisation Justifier une absence . . . . . Fiche descriptive du cas d’utilisation Ajouter un étudiant . . . . . . Fiche descriptive du cas d’utilisation Consulter le relevé d’absence étudiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11 Fiche descriptive du cas d’utilisation Gérer les justifications . . . . 2.12 Fiche descriptive du cas d’utilisation Consulter les statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pour un . . . . . . . . . . . . . . . . . . 26 26 26 26 26 34 35 36 37 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 . . . . . . . . . . . . . . . . . . . . . 51 53 54 54 55 55 56 56 57 57 58 58 59 60 60 61 61 62 62 63 63 Les relations Class-to-Class . . . . . . . . . . . . . . . Fiche descriptive de la classe Personne . . . . . . . . . Fiche descriptive de la classe Administrateur . . . . . Fiche descriptive de la classe Étudiant . . . . . . . . . Fiche descriptive de la classe Enseignant . . . . . . . . Fiche descriptive de la classe Chef département . . . . Fiche descriptive de la classe Responsable de formation Fiche descriptive de la classe Séance . . . . . . . . . . Fiche descriptive de la classe Module . . . . . . . . . . Fiche descriptive de la classe Groupe . . . . . . . . . . Fiche descriptive de la classe Faculté . . . . . . . . . . Fiche descriptive de la classe Spécialité . . . . . . . . . Fiche descriptive de la classe Département . . . . . . . Fiche descriptive de la classe Réclamation . . . . . . . Fiche descriptive de la classe Justification . . . . . . . Fiche descriptive de la classe Utilisateur Système . . . Fiche descriptive de la classe Demande de suppression Fiche descriptive de la classe Section . . . . . . . . . . Fiche descriptive de la classe ActionÉtudiantSéance . . Fiche descriptive de la classe Présence . . . . . . . . . Fiche descriptive de la classe Absence . . . . . . . . . 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 39 40 3.22 Schéma de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 4.2 4.3 4.4 4.5 4.6 4.7 Spécifications techniques de l’ordinateur 1 . . . . . . . . Spécifications techniques de l’ordinateur 2 . . . . . . . . Environnement de développement de l’application Web . les versions de la Raspberry PI . . . . . . . . . . . . . . Les méthodes HTTP . . . . . . . . . . . . . . . . . . . . Les codes HTTP . . . . . . . . . . . . . . . . . . . . . . Quelques versions d’Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 . 78 . 79 . 81 . 88 . 96 . 96 . 100 Chapitre 1 Introduction générale 1.1 Introduction générale Les technologies de l’information et de la communication sont exploitées via différentes ressources techniques pour garantir une manipulation correcte et fiable des données, autrement dit être capable de convertir, stocker, gérer, transmettre et communiquer des informations. Les ressources techniques sont regroupées par les catégories suivantes : • La microélectronique ; • L’équipement informatique, comme les serveurs et les logiciels ; • Les réseaux, les infrastructures et les systèmes de télécommunications ; • Les terminaux de télécommunication. Les services fournies par les Technologies de l’information et de la communication (TIC)s sont : • Les services de transmission de données ; • Les services informatiques ; • Les services de communication ; • Les services de commerce électronique. Les NTICs sont largement exploitées dans plusieurs domaines, on peut citer par exemple le vote et l’administration électronique dans le domaine de l’administration et la gouvernance, les technologies de géolocalisation dans le domaine du transport, l’accessibilité numérique dans le domaine des droits des personnes handicapées, dans l’éducation et l’enseignement par les universités numériques qui est le sujet de ce projet. 1.2 Description du projet La faculté des nouvelles technologies de l’information et de la communication est composée de trois départements : 9 CHAPITRE 1. INTRODUCTION GÉNÉRALE 10 1. Le département MI qui gère les étudiants de la première et la deuxième année du tronc commun. 2. Le département TLSI qui gère les étudiants des spécialités GL et SI. 3. Le département IFA qui gère les étudiants des spécialités SCI et TI. Dans chaque département, les étudiants sont organisés en sections. Chaque section est composée de plusieurs groupes. Chaque groupe d’étudiants assiste à des séances de travaux dirigés (TD) et de travaux pratiques (TP) dont la présence est obligatoire. Dans ces séances, la gestion des absences est effectuée manuellement par l’enseignant à travers une liste de présences. Si l’étudiant est absent, il doit présenter une justification valable au niveau de l’administration de son département. A la fin du semestre, l’enseignant doit envoyer une liste des absences pour ses groupes à l’administration du département concerné afin d’établir la liste des étudiants exclus. Un étudiant est dit exclus s’il a au maximum trois absences non justifiées ou cinq absences justifiées. 1.3 Problématique Le tâche de prise des absences dans la faculté des nouvelles technologies de l’information et de la communication est une tâche coûteuse en terme de temps car elle se fait d’une manière manuelle à l’aide des listes imprimées et d’une feuille de présences. Cette opération manuelle augmente le taux d’erreurs de la gestion des absences et des justifications et ne permet pas de maintenir la trace de ces information. Comment peut-on trouver une solution aux limitations de la gestion des absences manuelle à l’aide d’un système d’information ? 1.4 Solution proposée La solution proposée est de concevoir et réaliser un système d’information pour gérer les absences d’une manière automatique dans la faculté des nouvelles technologies de l’information et de la communication en utilisant les différentes ressources techniques afin de mettre en place un système fiable qui répond aux besoins suivants : • Permettre aux administrateurs du système la gestion des informations des étudiants, enseignants, modules et séances. • Permettre aux chefs des départements la gestion différentes équipes pédagogiques. • Permettre aux responsables de formations la consultation des statistiques. • Permettre aux enseignants la gestion des absences et des justificatifs des étudiants. • Permettre aux étudiants la consultation des relevés et la justification des absences. CHAPITRE 1. INTRODUCTION GÉNÉRALE 1.5 11 Le génie logiciel Le génie logiciel est la discipline qui s’intéresse aux procédures de développements des projets logiciels dans le but de livrer un produit fiable qui répond aux besoins et exigences du client tout en respectant les délais et les coûts. Autrement dit, le GL se préoccupe des procédés de fabrication des logiciels. • Le logiciel doit répondre aux besoins des utilisateurs ; • Le logiciel doit être de qualité ; • Les coûts doivent rester dans les limites prévues initialement ; • Les délais de livraison ne doivent pas dépasser les délais prévues. 1.5.1 Les approches du génie logiciel La discipline du génie logiciel comporte plusieurs activités et tâches, on peut citer les processus de développement, la gestion des projets, la modélisation des besoins, la sécurité, la gestion des risques ...etc Les quatre approches essentielles du GL sont : 1. L’approche de l’Orienté Objet (OO) ; 2. La modélisation des besoins ; 3. L’étude des besoins ; 4. Le processus de développement. Figure 1.1 : Les approches du génie logiciel. CHAPITRE 1. INTRODUCTION GÉNÉRALE 12 L’approche orienté objet L’orienté objet est un paradigme de programmation basé sur la notion d’objets. L’objet comporte les données dans la forme d’attributs et un comportement dans la forme de méthodes. Ce modèle abstrait représente aussi la relation entre les objets (relation d’association, composition, héritage... etc). La plupart des langages de programmation modernes supporte ce paradigme, on peut citer Java, Python, JavaScript, PHP et autres. La modélisation des besoins La modélisation des besoins est une approche importante du génie logiciel, elle consiste à illustrer les besoins des utilisateurs à travers des diagrammes et des pictogrammes pour améliorer la communication entre les membres de l’équipe de développement. Cette amélioration sert à diminuer les erreurs et assurer la qualité du logiciel produit. L’illustration des besoins se fait à la base des règles du modèle standard, en utilisant le Langage de modélisation unifié (Unified Modeling Language - UML) et à l’aide d’un outil piloté par ordinateur faciliter la tâche de modélisation. Le logiciel de modélisation utilisé pour réaliser les différents diagrammes de ce projet est StarUML. Figure 1.2 : StarUML version 3.1.1 Processus de développement Le processus de développement est une façon de définir les activités, les phases et la démarche à suivre lors du développement du projet logiciel. Il est essentiel de suivre un processus de développement afin de synchroniser les équipes de conception et de développement, éclaircir les activités et les tâches de chaque membre de l’équipe, et de déterminer le but final du projet (les délivrables). L’étude des besoins Cette approche consiste à étudier la faisabilité des besoins des utilisateurs. CHAPITRE 1. INTRODUCTION GÉNÉRALE 1.6 1.6.1 13 Le langage de modélisation unifié - UML Définition et historique UML est un langage de modélisation utilisé dans le domaine du génie logiciel, il définie un mécanisme standard de modélisation des systèmes d’information. Sa première apparition était en 1994-1995. En 1997, UML été adopté par l’OMG (Object Management Group) comme un standard de modélisation des systèmes d’information. En 2005, UML été publié par l’Organisation Internationale de Standardisation et adopté comme un standard ISO. L’utilisation d’un langage de modélisation par les concepteurs des systèmes d’information ne facilite pas seulement la compréhension de la structure des futurs systèmes, mais aussi de comprendre des systèmes d’information existants. La figure suivante représente la structure d’un système existant modélisé par un diagramme de classes du langage de modélisation unifié. Figure 1.3 : Diagramme de classes du NodeJS v0.8.12 CHAPITRE 1. INTRODUCTION GÉNÉRALE 1.6.2 14 L’importance de modélisation La modélisation offre une illustration des besoins et exigences exprimés par les futur utilisateurs, cette illustration est le point de liaison entre l’analyse et l’implémentation du projet. Figure 1.4 : Importance de la modélisation 1.6.3 Les usages d’UML 1. Visualisation : le but principal d’UML est de fournir une visualisation des besoins et des différents aspects du futur système à travers des diagrammes. 2. Spécification : UML facilite la spécification des : acteurs, cas d’utilisation, classes, attributs et des opérations. 3. Construction : UML est aussi utilisé pour la construction des projets logiciels grâce à la fonctionnalité de la génération du code pour différentes langages de programmation (par exemple Java).UML permet de modifier le code sur les gabarits générés au lieu de les définir de zéro. 4. Documentation : UML permet la documentation les différents diagrammes pour renforcer les spécifications du projet. 5. Maintenance : les modèles d’UML facilitent la compréhension des systèmes existants, ça résulte une maintenue rapide et efficace de ces derniers. CHAPITRE 1. INTRODUCTION GÉNÉRALE 15 Figure 1.5 : Les usages du langage de modélisation unifié 1.6.4 Les diagrammes d’UML Chaque aspect du système d’information est modélisé par un ou plusieurs diagrammes du langage de modélisation unifié. La version 2.0 d’UML comporte 9 diagrammes. Aspect Statique Dynamique Fonctionnel Description Identifie les propriétés des objets et leurs liaisons avec les autres objets. Définit le cycle de vie des objets en précisant : le comportement du système, les différents états des objets et les événements qui déclenchent les changements d’états. Précise les fonctionnalités liées aux objets. Table 1.1 : Les trois aspects d’un système d’information Diagramme de cas d’utilisation Le digramme de cas d’utilisation modélise l’aspect fonctionnel du système d’information. Il illustre les cas d’utilisation, les acteurs et leurs relations. C’est le diagramme principal du langage de modélisation unifié. Diagramme de classes Le diagramme de classes (DCL) représente les classes, ses définitions et les relations entre eux. Chaque classe est représentée par un nom d’identification, des attributs qui comporte les données de l’entité et des méthodes qui définissent le comportement de cette dernière. Le DCL modélise l’architecture conceptuelle d’une vue statique . CHAPITRE 1. INTRODUCTION GÉNÉRALE 16 Diagramme d’objets Le diagramme d’objets (DO) permet d’éclaircir le diagramme de classes. Il représente les relations entre les objets dans la mémoire et facilite la détection de la redondance. Diagramme d’activités Le diagramme d’activités (DA) modélise l’enchaı̂nement normal de l’interaction de l’utilisateur avec un cas d’utilisation, l’enchaı̂nement alternatif et les exceptions. Diagramme de séquence Le diagramme de séquence (DS) représente la succession chronologique des opérations invoquées par un acteur. Il illustre les interactions entre les objets et les acteurs sur l’axe des temps. Diagramme de composants Le diagramme de composants (DCO) décrit l’architecture physique du système d’information en terme de modules (ou composants) : fichiers sources, librairies, exécutables... etc. Il illustre la mise en œuvre physique des modèles conceptuels avec l’environnement de développement. Diagramme de déploiement Le diagramme de déploiement (DD) modélise l’architecture du matériel et illustre les nœuds hébergeant le système. Diagramme de communication Le diagramme de communication (DC) est une représentation simplifiée d’un diagramme de séquence. Il illustre l’échange des messages entre les objets. Le diagramme de séquence et de communication sont deux vue différentes mais logiquement équivalente d’un système d’information sur une même chronologie. Diagramme d’états-transitions Le diagramme d’états-transitions (DET) représente le cycle de vie des objets appartenant à une même classe. La modélisation du cycle de vie des objets par un DET est essentielle pour mettre en forme la dynamique du système d’information. CHAPITRE 1. INTRODUCTION GÉNÉRALE Aspect fonctionnel • Diagramme de cas d’utilisation Aspect statique 17 Aspect dynamique • Diagramme de classes • Diagramme d’activité • Diagramme d’objets • Diagramme de séquence • Diagramme de composants • Diagramme de déploiement • Diagramme de communication • Diagramme de étatstransitions Table 1.2 : Regroupement des diagrammes par aspect 1.7 1.7.1 Le processus unifié Définition Le processus unifié (UP) est un processus de développement des projets logiciels. Il est une méthode générique, itérative et incrémentale formée de composants. UP possède des caractéristiques partagées par les différentes variantes de ce dernier. Les caractéristiques du processus de développement unifié sont : 1. Il est un processus itératif et incrémental ; 2. Il est centré sur l’architecture du système ; 3. Il se focalise sur les facteurs de risque les plus élevés ; 4. Il est piloté par les cas d’utilisation du langage de modélisation unifié. 1.7.2 Les caractéristiques du processus unifié UP est itératif L’itération est une répétition d’une séquence d’instructions à un nombre fixe ou tant qu’une condition définie n’est pas vérifiée, pour but d’appliquer un traitement itératif sur des différentes données. Autrement dit, l’itération est une procédure qui exécute un groupe d’opérations de façon répétitive afin d’accomplir une condition. Elle prend en compte un ou plusieurs cas d’utilisation et traite en priorité les risques majeurs. CHAPITRE 1. INTRODUCTION GÉNÉRALE 18 Figure 1.6 : Développement par itérations successives UP est centré sur l’architecture Le processus unifié est centré sur un modèle architectural basé sur des différentes vues ; 1. Une vue logique. 2. Une vue de composants. 3. Une vue de processus. 4. Une vue de déploiement. UP est piloté par les cas d’utilisation Le but principal d’un système d’information est de satisfaire les besoins du client, le processus de développement est basé sur les cas d’utilisations qui spécifient les besoins. Un cas d’utilisation permet d’illustrer un ou plusieurs besoins, l’ensemble des cas d’utilisation décrivent les besoins fonctionnels du point de vue de l’utilisateur. Cet ensemble constitue le modèle de cas d’utilisation. UP focalise sur les risques majeurs Le processus de développement unifié assure l’identification des facteurs de risque les plus élevés qui sont de nature à bouleverser le plan, excéder le coût ou le délai du développement. 1.7.3 L’objectif du processus unifié L’objectif principal du processus unifié est de maı̂triser la complexité des projets logiciel et de répondre aux questions suivantes : CHAPITRE 1. INTRODUCTION GÉNÉRALE 19 1. QUI participe au projet ? 2. QUOI , le produit résultant ? 3. QUAND le produit sera livré ? 4. COMMENT doit-il être réalisé ? 1.7.4 L’architecture UP Le processus unifié est structuré selon une architecture bidirectionnelle représentées sur deux axes : 1. L’axe horizontal : c’est l’axe des temps, il illustre le déroulement du cycle de vie du processus de développement. 2. L’axe vertical : représente l’enchaı̂nement des activités. Figure 1.7 : Le cycle de vie du processus unifié 1.8 1.8.1 Les activités du processus unifié Expression des besoins L’expression des besoins consiste à définir et recenser les besoins fonctionnels et non fonctionnels du client afin d’élaborer le modèle des cas d’utilisation qui sera traduit par l’équipe du développement en fonctionnalités. CHAPITRE 1. INTRODUCTION GÉNÉRALE 1.8.2 20 Analyse Le modèle d’analyse assure une spécification détaillée du modèle de cas d’utilisation, il est écrit dans le langage des développeurs afin de faciliter la compréhension des cas d’utilisation aussi que la maintenance et la mise à jour du système. L’analyse permet de définir une architecture primaire du futur système d’information. Les documents résultants de l’activité de conception seront la plateforme de la conception. 1.8.3 Conception La conception permet d’acquérir une compréhension approfondie de l’architecture du système d’information. Elle est le point de départ de l’étape d’implémentation : elle permet de la décomposer en sous-systèmes et de l’abstraire. 1.8.4 Implémentation L’implémentation est l’étape de construction des sous-systèmes transcrits dans l’étape de conception, l’équipe de développement traduit les spécifications et les besoins du client en fonctionnalités tout en respectant l’architecture générale conçue et mise en place durant les autres activités. Cette étape consiste à construire le code source du système d’information pour le transformer en livrable qui répond aux besoins du client et offre une solution au problème posé. 1.8.5 Test Le test est une activité importante durant le cycle de vie du processus de développement, elle permet la vérification des résultats de l’implémentation et la détection des erreurs pour une intervention efficace. Les tests doivent être planifiés pour chaque itération du processus et implémentés par des cas de testes, les résultats de cette activité sont prise en considération dans les autres itérations. 1.9 1.9.1 Les phases du processus unifié Analyse des besoins Comme son nom l’indique, cette phase consiste à analyser les besoins principaux du point de vue de l’utilisateur. Elle permet d’élaborer une architecture générale du système à base des besoins, identifier les risques majeurs et mettre en place les délais et les coûts de réalisation du système d’information. 1.9.2 Élaboration La phase d’élaboration dépend des résultats de la phase d’analyse des besoins. Elle permet de préciser les cas d’utilisation et de concevoir l’architecture du système d’information. 1.9.3 Construction Dans cette phase, le produit sera construit à base des spécifications et des cas d’utilisations définis par le client. C’est la mise en place du système à base de l’architecture conçue. CHAPITRE 1. INTRODUCTION GÉNÉRALE 1.9.4 21 Transition La phase de transition livre le produit logiciel en version bêta qui sera testée par les utilisateurs. Le but des testes est de détecter les défauts de conception et de construction. Dans cette phase du processus de développement : une formation des utilisateurs et un service d’assistances pour accompagner les clients sont nécessaire ainsi que la correction des anomalies et les défauts détectés. 1.10 Conclusion Dans ce chapitre intitulé : Introduction générale on a présenté une description du projet et le problème posé afin de trouver une solution qui convient à ce dernier. On a aussi parlé du langage de modélisation unifié qui offre un moyen de visualisation standard et qui sera utilisé tout au long de ce projet. On a cité le processus unifié, ses activités et ses phases. La conception et le développement de ce projet seront réalisés à la base des phases et des activités du processus unifié. Chapitre 2 Analyse des besoins 2.1 Introduction L’analyse des besoins est la première étape du processus de développement unifié, elle consiste à spécifier les besoins fonctionnels et non-fonctionnels du client, identifier les différents acteurs et illustrer l’aspect fonctionnel du système à base du langage de modélisation unifié. 2.2 2.2.1 Expression des besoins Cahier des charges Le cahier des charges (CDC) est une forme de contrat entre l’équipe de développement de la solution et le client. Il décrit des besoins et les exigences du client et il sera utilisé comme une référence pour réponde à ces derniers. Il existe deux types de cahier des charges : 1. Un cahier des charges technique (CDCT) : il s’intéresse particulièrement aux exigences et contraintes techniques du produit. 2. Un cahier des charges fonctionnel (CDCF) : il s’intéresse que sur les besoins fonctionnels. Les exigences sont exprimées en terme de besoins et de services et non pas en terme de solutions et de moyens de réalisation. Les besoins des utilisateurs de ce projet sont exprimé par un cahier des charges technique. Cahier des charges du projet • Présentation et contexte du projet : 1. La description du projet est citée dans le chapitre 1 : Introduction générale. 2. Contexte du projet : une application mobile, un site Web et un appareil électronique. 3. Objectif du projet : automatiser la tâche de prise de présences et offrir une interface de gestion et de visualisation du système d’information. 22 CHAPITRE 2. ANALYSE DES BESOINS 23 • Besoins : – Administrateur : 1. 2. 3. 4. Ajout, Ajout, Ajout, Ajout, modification, modification, modification, modification, et et et et suppression suppression suppression suppression des des des des étudiants ; enseignants ; modules ; séances. Ces fonctionnalités doivent être accessibles via Internet à travers une page web. – Chef département : 1. 2. 3. 4. Affectation des séances aux enseignants ; Gestion des justifications ; Établissement de la liste des étudiants exclus ; Consultation des statistiques. Ces fonctionnalités doivent être accessibles via Internet à travers une page web. – Responsable de formation : 1. Consultation des statistiques. Cette fonctionnalité doit être accessibles via Internet à travers une page web. – Enseignant : 1. 2. 3. 4. 5. 6. 7. Modification et suppression du profil ; Faire l’appel pour un groupe (en exploitant les nouvelles technologies) ; Modification du relevé d’absences d’un étudiant ; Enregistrement de la Justification d’une absence d’un étudiant ; Consultation du relevé des absences d’un groupe ou d’un étudiant ; Établissement de la liste des étudiants exclus ; Consultation des statistiques pour les groupes. Ces fonctionnalités doivent être accessibles via Internet á travers une application mobile. – Étudiant : 1. Consultation du relevé d’absences ; 2. Justification d’une absence. Ces fonctionnalités doivent être accessibles via internet á travers une page web ou application mobile. • Contraintes : – L’application Web doit être implémentée en JavaEE ; – L’application mobile doit être native et développée en Java ; – La base de données doit implémenter le modèle relationnel et interrogée par le language SQL ; – L’appareil électronique doit être construit à la base d’une Raspberry PI ; – L’appareil électronique doit utiliser la technologie de la radio-identification. CHAPITRE 2. ANALYSE DES BESOINS 24 • Résultats attendus : – Développement du site Web – Développement de l’application mobile – Développement d’une Applicaition Programming Interface (API) – Conception et réalisation de l’appareil électronique – Conception et mise en service de la base de données 2.2.2 Identification des acteurs Définition Le but principal de la conception et la construction des systèmes d’information est de répondre aux besoins des utilisateurs. L’acteur détermine la façon dont le système sera utilisé, il est considéré comme le point de départ de la modélisation de l’architecture du système conçu. Un acteur peut être : • Un rôle joué par un utilisateur direct qui invoque une intéraction avec le système ; • Un système externe qui interagit avec le system en cours de développement ; • Un appareil externe qui interagit avec le système ; • Le temps est considéré comme acteur quand il s’agit des éventements exécutes régulièrement après un certain intervalle de temps. Il faut bien noté que l’acteur est le rôle joué par l’utilisateur et n’est pas la personne qui joue ce rôle. Identification des acteurs L’identification des acteurs est l’activité la plus importante durant l’analyse des besoins. Cette activité peut durer tout au long du processus de développement. Le point de départ de l’identification des acteurs est le cahier des charges qui exprime les exigences du client. Le CDC ne couvre pas tous les acteurs du qui interagissent avec le système. L’identification des besoins et des classes peut révéler d’autres acteurs, aussi que la modélisation des différents aspects du système. On peut identifier les acteurs potentiels du système en posant les questions suivantes : 1. Qui sont les acteurs principaux du système ? 2. Qui sont les acteurs secondaires du système ? 3. Qui invoque les interactions avec le système ? 4. Quels sont les systèmes et appareils externes qui interagissent avec le système sous-développement ? CHAPITRE 2. ANALYSE DES BESOINS 25 La liste suivante représente les acteurs du système de gestion des absences de la faculté NTIC : 1. Administrateur 2. Responsable de formation 3. Chef département 4. Enseignant 5. Étudiant 2.2.3 Diagramme de contexte statique Le diagramme de contexte statique identifie l’environnement extérieur du système en représentant les interactions des acteurs avec ce dernier. Figure 2.1 : Le diagramme de contexte statique. CHAPITRE 2. ANALYSE DES BESOINS 2.2.4 Documentation des acteurs Les fiches descriptives suivantes documentent les acteurs du futur système. Acteur Type Description A1-Administrateur Acteur principal et concret. L’acteur administrateur utilise le système principalement pour gérer les comptes des autres utilisateurs : ajouter des nouveaux comptes, modifier et supprimer des comptes existants. Afin de garantir ses fonctionnalités, l’administrateur doit être authentifié par l’application Web. Table 2.1 : La fiche descriptive de l’acteur administrateur Acteur Type Description A2-Enseignant Acteur principal et concret. Il généralise les deux acteurs A3-Responsable de formation et A4-Chef département L’acteur enseignant utilise le système pour gérer les absences et consulter des statistiques des étudiants de ses groupes. Il doit être authentifié par l’application mobile afin qu’il peut utiliser ses fonctionnalités. Table 2.2 : La fiche descriptive de l’acteur enseignant Acteur Type Description A3-Responsable de formation Acteur principal et concret. Il spécifie l’acteur A2-Enseignant. Plus que les fonctionnalités de l’acteur enseignant, le responsable de formation peut consulter des statistiques de tous les étudiants de la formation. Il doit être authentifié par l’application Web pour utiliser ses fonctionnalités. Table 2.3 : La fiche descriptive de l’acteur responsable de formation Acteur Type Description A4-Chef département Acteur principal et concret. Il spécifie l’acteur A2-Enseignant. Plus que les fonctionnalités de l’acteur enseignant, le chef département peut consulter des statistiques de tous les étudiants de la formation, affecter les séances et gérer les justifications. Il doit être authentifié par l’application Web pour utiliser ses fonctionnalités. Table 2.4 : La fiche descriptive de l’acteur chef département Acteur Type Description A5-Étudiant Acteur principal et concret. L’acteur étudiant utilise le système pour consulter et justifier ses absences, marquer ses présences et envoyer ses réclamations à l’administration. Il doit être authentifié par l’application mobile afin qu’il peut utiliser ses fonctionnalités. Table 2.5 : La fiche descriptive de l’acteur étudiant 26 CHAPITRE 2. ANALYSE DES BESOINS 2.3 27 Identification des besoins Un besoin est une exigence spécifiée par le client ou l’équipe de développement et citée dans le cahier des charges. Il existe deux types de besoins : 1. Un besoin fonctionnel (BF) est un besoin précisé par le client dans le cahier des charges, ce besoin requis par le client n’est pas négociable et il s’appelle un besoin primaire. 2. Un besoin non-fonctionnel (BNF) est aussi une exigence du client, sauf que cette dernière est soit optionnelle ou une contrainte liée à l’implémentation. Un BNF peut être spécifié par le client et/ou par l’équipe de développement. 2.3.1 Les besoins fonctionnels du projet • Le système doit être accessible par : – L’étudiant à travers une application mobile. – L’enseignant à travers une application mobile. – Le chef département à travers une application Web. – Le responsable de formation à travers une application Web. – L’administrateur à travers une application Web. Le système doit permettre : • Á l’administrateur : – D’ajouter, modifier et supprimer des étudiants ; – De consulter la liste des étudiants ; – D’ajouter, modifier ou supprimer des enseignants ; – De consulter la liste des enseignants ; – D’ajouter, modifier ou supprimer des modules ; – De consulter la liste des modules ; – D’ajouter, modifier ou supprimer des séances ; – De consulter la liste des séances ; – D’ajouter, modifier ou supprimer des administrateurs ; – De consulter la liste des administrateur. • Au chef département : – D’affecter des séances au enseignants ; – De gérer des justifications ; – D’établir la liste des étudiants exclus ; – De consulter des statistiques. • Á l’étudiant : CHAPITRE 2. ANALYSE DES BESOINS – De consultation le relevé d’absence ; – De justification une absence. • Á l’enseignant : – De modifier son profile ; – De faire l’appel ; – De modifier le relevé d’absence d’un étudiant ; – D’enregistrer une justification ; – De consulter le relevé d’absence d’un groupe ou un étudiant ; – D’établir la liste des étudiants exclus ; – De consultation des statistiques. • Au responsable de formation : – De consulter des statistiques. 2.3.2 Les besoins non-fonctionnels du projet • Les utilisateurs du système doivent être authentifiés. • L’application Web doit être implémentée en JavaEE. • L’application mobile doit être native et développée en Java. • La base de données doit implémenter le modèle relationnel et interrogée par le langage SQL. • L’appareil électronique doit être construit à la base d’une Raspberry PI. • L’appareil électronique doit utiliser la technologie de la radio-identification. 28 CHAPITRE 2. ANALYSE DES BESOINS 2.4 2.4.1 29 Spécification des besoins Identification des cas d’utilisation Un cas d’utilisation est une série des interactions d’un acteur avec le système pour accomplir une tâche précise. Les cas d’utilisation décrivent ce que le système doit faire mais ils ne spécifient pas comment le système fait l’interaction. L’identification des cas d’utilisation est faite à la base du cahier des charges, des spécifications et des besoins du client. La documentation et la modélisation des cas d’utilisation permet une meilleure compréhension du système. La liste suivante identifie 7 cas d’utilisation qui seront plus-tard documentés et modélisés par les différents diagrammes d’UML : 1. Le cas d’utilisation Faire l’appel invoqué par l’acteur A2-Enseignant. 2. Le cas d’utilisation Faire une réclamation invoqué par l’acteur A5-Étudiant. 3. Le cas d’utilisation Justifier une absence invoqué par l’acteur A5-Étudiant. 4. Le cas d’utilisation Ajouter un étudiant invoqué par l’acteur A1-Administrateur. 5. Le cas d’utilisation Consulter le relevé d’absence invoqué par l’acteur A2-Enseignant. 6. Le cas d’utilisation Gérer les justifications invoqué par l’acteur A4-Chef département. 7. Le cas d’utilisation Consulter les statistiques invoqué par l’acteur A2-Enseignant. 2.4.2 Diagrammes de cas d’utilisation Le Diagramme de cas d’utilisation (DCU) modélise les différents cas d’utilisation identifiés en analysant le cahier des charges. Il illustre aussi les relations entre les acteurs et les cas d’utilisation. Un cas d’utilisation est représente par une ellipse. Il existe 3 types de relations modélisées par le diagramme de cas d’utilisation : 1. La relation Acteur-Acteur : elle illustre la relation entre deux acteurs, cette relation est modélisée par une flèche vide. Le sens de la flèche indique le type de relation : • Une Généralisation. • Une Spécification. 2. La relation Acteur-Cas d’utilisation : elle modélise la relation entre un acteur et un cas d’utilisation par une ligne droite, la première extrémité de la ligne spécifie l’acteur qui invoque le cas d’utilisation et la deuxième extrémité indique le cas d’utilisation invoqué. 3. La relation Cas d’utilisation-Cas d’utilisation : elle modélise la relation entre deux cas d’utilisation par une flèche, cette modélisation indique le type de relation entre ces derniers : • Une relation d’inclusion : un cas d’utilisation doit être obligatoirement inclus dans l’autre cas. • Une relation d’extension : un cas d’utilisation peut étendre l’autre cas. Les figures suivantes représente les diagrammes des cas d’utilisation regroupés par acteur. CHAPITRE 2. ANALYSE DES BESOINS Figure 2.2 : Diagramme de cas d’utilisation A1-Administrateur. 30 CHAPITRE 2. ANALYSE DES BESOINS Figure 2.3 : Le diagramme de cas d’utilisation A2-Enseignant. Figure 2.4 : Diagramme de cas d’utilisation A3-Responsable de formation. 31 CHAPITRE 2. ANALYSE DES BESOINS Figure 2.5 : Diagramme de cas d’utilisation A4-Chef département. Figure 2.6 : Diagramme de cas d’utilisation A5-Étudiant. 32 CHAPITRE 2. ANALYSE DES BESOINS 2.4.3 33 Documentation des cas d’utilisation La documentation des acteurs est faite par des fiches descriptives qui contiennent les information suivantes : • Le nom de cas d’utilisation ; • L’acteur qui invoque le cas d’utilisation ; • Les pré-conditions qui doivent être vérifiées pour que le cas d’utilisation réussit son exécution ; • Le scénario nominal qui indique les étapes de déroulement du cas d’utilisation dans les conditions normales ; • Le scénario alternatif qui indique le comportement du système dans les conditions anormales ; • Le scénario d’exception qui indique le comportement du système en cas d’interruption du scénario normal ; • Les post-conditions qui indiquent le résultat après l’exécution du cas d’utilisation. Les tableaux suivants documentent les 7 cas d’utilisation cités dans la section d’Identification des cas d’utilisation. CHAPITRE 2. ANALYSE DES BESOINS Nom de cas d’utilisation Acteur Objectifs Faire l’appel A2-Enseignant • Permettre aux enseignants de marquer la présence manuellement en cas de malfonctionnement du système de prise de présences automatique. Pré-conditions • L’enseignant doit être authentifié. Scénario nominal 1. L’enseignant accède à la page ”faire l’appel manuellement” ; 2. Le système affiche la liste des séances ; 3. L’enseignant choisit la séance ; 4. Le système affiche la liste des étudiants ; 5. L’enseignant fait l’appel et envoie la liste de présence des étudiants au système ; 6. Le système enregistre le relevé de présences des étudiants. Scénario alternatif Scénario d’exception / • E.1. L’enseignant choisit d’annuler l’opération, l’enchaı̂nement démarre après l’étape 3. Post-conditions • Le système met à jour le relevé de présence des étudiants du groupe sélectionné. Table 2.6 : Fiche descriptive du cas d’utilisation Faire l’appel 34 CHAPITRE 2. ANALYSE DES BESOINS Nom de cas d’utilisation Acteur Objectifs 35 Faire une réclamation A5-Étudiant • Permettre aux étudiants de transmettre une réclamation à l’administration du département à travers le système. Pré-conditions • L’étudiant doit être authentifié. Scénario nominal 1. L’étudiant accède à la page ”Faire une réclamation” ; 2. Le système affiche un formulaire à remplir avec les détails de réclamation ; 3. L’étudiant remplit le formulaire et l’envoie ; 4. Le système enregistre la réclamation et affiche un message de succès ; 5. Le système enregistre la réclamation. Scénario alternatif / Scénario d’exception • E.1. L’étudiant remplit le formulaire de réclamation sans l’envoyer. L’enchaı̂nement démarre après l’étape 2. • E.2. L’étudiant choisit d’annuler l’opération, l’enchaı̂nement démarre après l’étape 3. Post-conditions • Le système met à jour la liste des réclamations. Table 2.7 : Fiche descriptive du cas d’utilisation Faire une réclamation CHAPITRE 2. ANALYSE DES BESOINS Nom de cas d’utilisation Acteur Objectifs 36 Justifier une absence A5-Étudiant • Permettre aux étudiants de transmettre une justification d’absence à l’administration du département à travers le système. Pré-conditions • L’étudiant doit être authentifié. Scénario nominal 1. L’étudiant accède à la page pour justifier une absence ; 2. Le système affiche l’application de galerie ; 3. L’étudiant choisit la photo de la justification ; 4. L’étudiant envoie la justification ; 5. Le système affiche un message de succès ; 6. Le système enregistre la justification. Scénario alternatif / Scénario d’exception • E.1. L’étudiant choisit une photo de la justification sans l’envoyer. L’enchaı̂nement démarre après l’étape 3. • E.2. L’étudiant choisi d’annuler l’opération, l’enchaı̂nement démarre après l’étape 3. Post-conditions • Le système met à jour la liste des justifications. Table 2.8 : Fiche descriptive du cas d’utilisation Justifier une absence CHAPITRE 2. ANALYSE DES BESOINS Nom de cas d’utilisation Acteur Objectifs 37 Ajouter un étudiant A1-Administrateur • Permettre aux administrateurs de créer des comptes pour les étudiants. Pré-conditions • L’administrateur doit être authentifié. Scénario nominal 1. L’administrateur accède à la page pour ajouter un étudiant ; 2. Le système affiche un formulaire pour remplir les informations de l’étudiant ; 3. L’administrateur remplit le formulaire et l’envoie ; 4. Le système vérifie les informations ; 5. Le système enregistre les informations et affiche un message de succès. Scénario alternatif • 4.a. Les informations entrées par l’administrateur ne sont pas valides. – a. Le système affiche un message d’erreur et redirige l’administrateur vers l’étape 2. Scénario d’exception • E.1. L’administrateur choisit d’annuler l’opération, l’enchaı̂nement démarre après l’étape 3. Post-conditions • Le système met à jour la liste des étudiants. Table 2.9 : Fiche descriptive du cas d’utilisation Ajouter un étudiant CHAPITRE 2. ANALYSE DES BESOINS Nom de cas d’utilisation Acteur Objectifs 38 Consulter le relevé d’absence pour un étudiant A2-Enseignant • Permettre aux enseignants de consulter les absences de ses étudiants. Pré-conditions • L’enseignant doit être authentifié. Scénario nominal 1. L’enseignant choisit de consulter le relevé des absences ; 2. Le système affiche la liste des modules. ; 3. L’enseignant choisit le module qui convient ; 4. Appel au cas d’utilisation Rechercher ; 5. L’enseignant choisit l’étudiant concerné par la consultation des absences ; 6. Le système affiche le relevé de l’étudiant choisi. Scénario alternatif • 3.a. L’enseignant choisit un étudiant qui n’appartient pas a ses groupes. – a. Le système affiche un message d’erreur et redirige l’enseignant vers l’étape 2. Scénario d’exception • E.1. L’enseignant ne sélectionne pas un étudiant après la recherche, l’enchaı̂nement démarre après l’étape 2. Post-conditions / Table 2.10 : Fiche descriptive du cas d’utilisation Consulter le relevé d’absence pour un étudiant CHAPITRE 2. ANALYSE DES BESOINS Nom de cas d’utilisation Acteur Objectifs 39 Gérer les justifications - Accepter A4-Chef département • Permettre au chef département de gérer les justifications. Pré-conditions • Le chef département doit être authentifié. Scénario nominal 1. Le chef département accède à la page ”Gérer les justifications”. 2. Le système affiche une liste des justifications. 3. Le chef département choisit une justification. 4. Le système affiche la justification. 5. Le chef département clique sur le bouton ”Accepter la justification”. 6. Le système affiche un message de succès ”justification acceptée”. Scénario alternatif / Scénario d’exception • E.1. Le chef de département choisi d’annuler l’opération, l’enchaı̂nement démarre après l’étape 3. Post-conditions • Le système met à jour le statut de la justification. Table 2.11 : Fiche descriptive du cas d’utilisation Gérer les justifications CHAPITRE 2. ANALYSE DES BESOINS Nom de cas d’utilisation Acteur Objectifs 40 Consulter les statistiques A2-Enseignant • Permettre à l’enseignant de consulter les statistiques pour ses groupes. Pré-conditions • L’enseignant doit être authentifié. Scénario nominal 1. L’enseignant choisit e consulter les statistiques ; 2. Le système affiche la liste des modules ; 3. L’enseignant choisit le moule qui convient ; 4. Le système affiche la liste de ses groupes. 5. L’enseignant choisit le groupe qui convient. 6. Le système affiche des statistiques sur le groupe sélectionné. Scénario alternatif / Scénario d’exception • E.1. L’enseignant choisi d’annuler l’opération, l’enchaı̂nement démarre après l’étape 2. Post-conditions / Table 2.12 : Fiche descriptive du cas d’utilisation Consulter les statistiques CHAPITRE 2. ANALYSE DES BESOINS 2.4.4 41 Diagrammes de séquence système Le diagramme de séquence système modélise les différentes interactions de l’utilisateur avec le système. Les interactions sont le scénario nominal, alternatif et le scénario d’exception décrits dans la fiche descriptive du cas d’utilisation. Le diagramme de séquence système est modélisé sur l’axe des temps, le premier axe illustre l’acteur qui invoque le cas d’utilisation et le deuxième axe illustre le système. Chaque interaction est illustrée par une flèche, chaque flèche représente un message. Il existe différents types de messages modélisés par le diagramme de séquence système : • Message synchrone : représenté par une flèche pleine. • Message asynchrone : représenté par une flèche. • Self-message : représenté par une flèche pleine, le point de départ et le point d’arrivé doivent être sur le même axe des temps. Le scénario alternatif est représenté par un cadre alt, le scénario d’exception par un cadre break et l’appel à un autre cas d’utilisation par un cadre ref . Les figures suivantes représentent les diagrammes de séquence système des 7 cas d’utilisations cités dans ce chapitre. CHAPITRE 2. ANALYSE DES BESOINS Figure 2.7 : Diagramme de séquence système Consulter le relevé des absences. 42 CHAPITRE 2. ANALYSE DES BESOINS Figure 2.8 : Diagramme de séquence système Consulter les statistiques. 43 CHAPITRE 2. ANALYSE DES BESOINS Figure 2.9 : Diagramme de séquence système Faire l’appel. 44 CHAPITRE 2. ANALYSE DES BESOINS Figure 2.10 : Diagramme de séquence système Faire une réclamation. 45 CHAPITRE 2. ANALYSE DES BESOINS Figure 2.11 : Diagramme de séquence système Gérer les justifications (Accepter). 46 CHAPITRE 2. ANALYSE DES BESOINS Figure 2.12 : Diagramme de séquence système Justifier une absence. 47 CHAPITRE 2. ANALYSE DES BESOINS Figure 2.13 : Diagramme de séquence système Ajouter un étudiant. 48 CHAPITRE 2. ANALYSE DES BESOINS 2.5 49 Conclusion Dans ce chapitre, on a établit l’étude préliminaire du futur système de gestion des absences de la faculté des nouvelles technologies de l’information et de la communication. Un cahier des charges technique a été rédigé afin de spécifier les besoins des utilisateurs, à partir duquel, une liste des fiches descriptives est élaborée afin d’identifier et documenter les différents acteurs. Après la documentation des acteurs, les cas d’utilisation ont été identifiés et documentés par des fiches descriptives. En dernier lieu, un échantillon des cas d’utilisation a été sélectionné pour modéliser l’aspect fonctionnel (digrammes de cas d’utilisation) et dynamique (diagrammes de séquence) du futur système. Chapitre 3 Conception 3.1 Introduction La conception est la deuxième partie du cycle de développement d’un logiciel, elle consiste à fournir des documents qui décrivent l’aspect structurel du futur système. Autrement dit, la tâche de conception aide à mieux comprendre l’architecture générale. Pour décrire le plan structurel, le système doit être basé sur un paradigme de programmation. L’approche qu’on va suivre dans ce projet est l’orientée objet, elle définit les différentes entités sous forme de classes qui seront instanciés plus tard en objets, ces objets interagissent entre eux afin de donner un comportement au système. 3.2 3.2.1 Diagramme de classe conceptuel Identification et documentation des classes La première étape de la conception est l’identification et la documentation des classes. Comme son nom l’indique, cette étape identifie les différentes entités du système qui peuvent être des classes puis les documenter afin de donner le maximum des informations aux réalisateurs du projet. Une classe est une abstraction des objets, elle décrit la structure interne des données manipulées par cette dernière via des attributs et elle définit le comportement des objets instanciée de cette classe via des méthodes. Une classe peut avoir des relations vers une ou plusieurs classes, les relations peuvent être de type composition, agrégation, association, généralisation... Le tableau suivant définit en bref les relations class-to-class utilisés dans la conception du projet : 50 CHAPITRE 3. CONCEPTION Relation Association 51 Définition L’association entre deux classes est représentée par une ligne droite, elle indique une connexion bidirectionnelle entre ces derniers. L’agrégation est une forme spéciale de l’association, elle indique le lien de composition entre deux classes avec une contrainte, si l’agrégeant est supprimé, l’agrégé ne va pas disparaı̂tre du système. Elle est représentée par une ligne droite qui se termine par un losange vide. Même définition que l’agrégation, sauf que si on supprime l’agrégeant, l’agrégé doit forcément disparaı̂tre du système. Elle est représentée par une ligne droite qui se termine par un losange plein. La généralisation (appelée aussi Héritage) est une relation entre deux classes. Elle consiste à héritier la structure et le comportement de la classe mère aux classes filles. Elle est représentée par une ligne droite qui finit par une flèche vide. La dépendance est une association directe avec un sens unique entre deux classes, elle indique que les objets de la première classe dépendent des objets de la deuxième classe. On trouve cette relation souvent entre les Classes et les Énumérations. Elle est représentée par une ligne discontinue qui se termine par une flèche. Agrégation Composition Généralisation Dépendance Table 3.1 : Les relations Class-to-Class Identification des classes L’identification des classes se fait par l’analyse des documentations précédentes (fiches descriptives des acteurs et des cas d’utilisation), le cahier des charges et les scénarios d’exécutions afin d’élaborer une liste des classes candidates (qui peuvent être des entités du système). La liste suivante représente les classes candidates du futur système : 1. Administrateur 8. Groupe 2. Étudiant 9. Faculté 3. Enseignant 10. Département 4. Chef de département 5. Responsable de formation 11. Spécialités 6. Séance 12. Réclamation 7. Module 13. Justification La liste des classes identifiées dans les documentations précédentes n’est pas une liste finale, elle peut être étendue par des classes abstraites, des classes entité et/ou des énumérations tout dépend des besoins des utilisateurs et de la vision du concepteur pour fournir un document complet qui représente la structure du futur système. CHAPITRE 3. CONCEPTION Les classes suivantes complémente la liste des classes candidate : 14. Personne 15. UtilisateurSystème 16. DemandeSuppression 17. Section 18. ActionÉtudiantEnseignant 19. Présence 20. Absence Et les énumérations suivantes : 21. EnumDépartements 22. EnumSpécialités 23. EnumÉtatsRéclamations 24. EnumÉtatsJustifications 25. EnumGrades 52 CHAPITRE 3. CONCEPTION 53 Documentation des classes Après l’identification des classes qui représentent les entités du système, une documentation doit être mise en place afin de donner des informations sur les différentes classes : ses attributs, ses relations, son rôle dans le système et sa complexité. La visibilité des attributs doit être spécifiée dans la documentation, un attribut public est accessible par les objets qui sont instanciés de tous les classes du système, un attribut private est accessible uniquement par les objets instanciés de la même classe et un attribut protected est accessible uniquement par les objets instanciés de la classe mère ou des classes dérivées. Les méthodes aussi ont aussi un degré de visibilité, les mêmes règles de visibilités des attributs sont appliquées sur les méthodes qui définissent le comportement du système. La complexité des classes est mesurée par le nombre d’attributs, nombre de relations et le rôle de la classe. La documentation des classes est présentée par des fiches descriptives, les tableaux suivants représentent les fiches descriptives des classes identifiées dans la liste ci-dessus. Nom de la classe Description Relations Attributs Personne C’est une classe abstraite des entités humaines du système. Elle est la classe mère des classes suivantes : UtilisateurSystème et Administrateur. Cette classe comporte les attributs suivants : 1. Nom : public 2. Prénom : public 3. Date de naissance : public 4. Adresse : public 5. Numéro de téléphone : public 6. Sexe : public Rôle Complexité Son rôle est de définir la structure des données et le comportement en commun des entités humaines du système Facile Table 3.2 : Fiche descriptive de la classe Personne CHAPITRE 3. CONCEPTION Nom de la classe Description Relations 54 Administrateur Cette classe représente les détails de l’administrateur du système. Cette classe a : • 4 relations d’association avec les classes : DemandeSuppression, UtilisateurSystème, Module et Séance ; • Elle est dérivée de la classe Personne. Attributs La classe Administrateur n’a aucun attribut de particulier, sauf les attributs qu’elle hérite de sa classe mère Son rôle est de sauvegarder et manipuler les données de l’administrateur du système et garantir ses fonctionnalités spécifiées dans le cahier des charges et décrites dans le diagramme de cas d’utilisation. Moyenne Rôle Complexité Table 3.3 : Fiche descriptive de la classe Administrateur Nom de la classe Description Relations Étudiant Cette classe représente les détails de l’utilisateur principal du système. Cette classe a : • Elle est dérivée de la classe UtilisateurSystème ; • Une seule relation d’association avec la classe Réclamation ; • 3 relations d’agrégation avec les classes Groupe, Absence et Présence, la classe Étudiant est l’agrégeant de la classe Groupe, et l’agrégé des classes Présence et Absence ; • Une classe-association avec la relation d’association Étudiant-Séance et Étudiant-Absence. Attributs Rôle Complexité Table 3.4 : Fiche descriptive de la classe Étudiant CHAPITRE 3. CONCEPTION Nom de la classe Description Relations 55 Enseignant Cette classe représente les détails de l’enseignant. Cette classe a : • 3 relations d’association avec les classes : Module, Justification et DemandeSuppression ; • Une relation d’agrégation avec la classe Département, la classe Enseignant est l’agrégeant ; • Elle est dérivée de la classe UtilisateurSystème. Attributs La classe Enseignant a les attributs qu’elle hérite de sa classe mère, en plus les attributs suivants : 1. Grade : public Rôle Son rôle est de sauvegarder et manipuler les données de l’utilisateur principal du système (l’étudiant) et garantir ses fonctionnalités essentielles comme la justification d’une absence, la consultation des relevés et de la liste des exclus... Difficile Complexité Table 3.5 : Fiche descriptive de la classe Enseignant Nom de la classe Description Relations Chef département Cette classe représente les détails du chef de département. Cette classe a : • 3 relations d’association avec les classes : Module, Justification et DemandeSuppression ; • Une relation d’agrégation avec la classe Département, la classe Enseignant est l’agrégeant ; • Elle est dérivée de la classe Enseignant. Attributs Rôle Complexité La classe Chef Département n’a aucun attribut de particulier, sauf les attributs qu’elle hérite de sa classe mère. Son rôle est de sauvegarder et manipuler les données de l’acteur : chef département et garantir les fonctionnalités définies dans le cahier des charges. Moyenne Table 3.6 : Fiche descriptive de la classe Chef département CHAPITRE 3. CONCEPTION Nom de la classe Description Relations 56 Responsable de formation Cette classe représente les détails du responsable de formation. Cette classe a : • Une seule relation d’association avec a classe Spécialité ; • Elle est dérivée de la classe Enseignant. Attributs Rôle Complexité La classe ResponsableFormation n’a aucun attribut de particulier, sauf les attributs qu’elle hérite de sa classe mère. Son rôle est de sauvegarder et manipuler les données de l’acteur : responsable de formation et de garantir les fonctionnalités définies dans le cahier des charges. Moyenne Table 3.7 : Fiche descriptive de la classe Responsable de formation Nom de la classe Description Relations Séance Cette classe représente l’entité Séance du système. Cette classe a : • 2 relations d’association avec les classes : Administrateur et Étudiant ; • Une relation de composition avec la classe Module, la classe Séance est l’agrégeant. Attributs La classe Enseignant a les attributs suivants : 1. Identifiant : private 2. IdentifiantPublique : public 3. Date : public 4. HeureDébut : public 5. HeureFin : public Rôle Complexité Son rôle est de sauvegarder et manipuler les données de l’entité Séance. Facile Table 3.8 : Fiche descriptive de la classe Séance CHAPITRE 3. CONCEPTION Nom de la classe Description Relations 57 Module Cette classe représente l’entité Module du système. Cette classe a : • 2 relations d’association avec les classes : Administrateur et Enseignant ; • Une relation de composition avec la classe Séance, la classe Séance est l’agrégé. Attributs La classe Enseignant a les attributs suivants : 1. Identifiant : private 2. IdentifiantPublique : public 3. NomModule : public 4. NomAbrégéModule : public Rôle Complexité Son rôle est de sauvegarder et manipuler les données de l’entité Module. Facile Table 3.9 : Fiche descriptive de la classe Module Nom de la classe Description Relations Groupe Cette classe représente l’entité Groupe du système. Cette classe a : • 2 relations d’agrégation avec les classes : Section et Étudiant, la classe Groupe est l’agrégeant de la classe Section et l’agrégé de la classe Étudiant ; Attributs La classe Groupe a les attributs suivants : 1. Identifiant : private 2. IdentifiantPublique : public 3. NomGroupe : public Rôle Complexité Son rôle est de sauvegarder et manipuler les données de l’entité Groupe. Facile Table 3.10 : Fiche descriptive de la classe Groupe CHAPITRE 3. CONCEPTION Nom de la classe Description Relations Attributs 58 Faculté Cette classe représente l’entité Faculté du système. La classe Faculté a une seule relation d’agrégation avec la classe Département, elle est l’agrégé de cette relation. La classe Faculté a les attributs suivants : 1. Identifiant : private 2. IdentifiantPublique : public 3. NomFaculté : public 4. NomAbrégéFaculté : public 5. AdresseFaculté : public 6. NuméroTéléphoneFaculté : public Rôle Complexité Son rôle est de sauvegarder et manipuler les données de l’entité Faculté. Facile Table 3.11 : Fiche descriptive de la classe Faculté Nom de la classe Description Relations Spécialité Cette classe représente l’entité Spécialité du système. Cette classe a : • 3 relations d’agrégation avec les classes Département, Section et Enseignant la classe Spécialité est l’agrégeant de la relation avec la classe Département et l’agrégé de la relation avec la classe Section et Enseignant ; • Une relation de dépendance avec l’énumération EnumSpécialités Attributs La classe Spécialité a les attributs suivants : 1. Identifiant : private 2. IdentifiantPublique : public 3. NomSéction : private 4. NomAbrégéSéction : public Rôle Complexité Son rôle est de sauvegarder et manipuler les données de l’entité Section. Facile Table 3.12 : Fiche descriptive de la classe Spécialité CHAPITRE 3. CONCEPTION Nom de la classe Description Relations 59 Département Cette classe représente l’entité Département du système. La classe Département a : • 3 relations d’agrégation avec les classes : Faculté, Spécialité et Enseignent. La classe Département est l’agrégé de la classe Spécialité et Enseignant, et l’agrégeant de la classe Faculté ; • Une relation d’association avec la classe Chef Département ; • Une relation de dépendance avec l’énumération EnumDépartements. Attributs La classe Département a les attributs suivants : 1. Identifiant : private 2. IdentifiantPublique : public 3. NomDépartement : public 4. NomAbrégéDépartement : public 5. AdresseDépartement : public 6. NuméroTéléphoneDépartement : public Rôle Complexité Son rôle est de sauvegarder et manipuler les données de l’entité Département. Facile Table 3.13 : Fiche descriptive de la classe Département CHAPITRE 3. CONCEPTION Nom de la classe Description Relations 60 Réclamation Cette classe représente l’entité Réclamation du système. Cette classe a : • 2 relations d’association avec les classes Étudiant et ChefDépartement ; • Une relation de dépendance avec l’énumération EnumÉtatsRéclamations. Attributs La classe Réclamation a les attributs suivants : 1. Identifiant : private 2. IdentifiantPublique : public 3. DescriptionRéclamation : public 4. ÉtatRéclamation : public Rôle Son rôle est de sauvegarder et manipuler les données de l’entité Réclamation. Facile Complexité Table 3.14 : Fiche descriptive de la classe Réclamation Nom de la classe Description Relations Justification Cette classe représente l’entité Justification du système. Cette classe a : • 2 relations d’association avec les classes ChefDépartement et Enseignant ; • La classe Justification est une classe-association de la relation d’association Étudiant-Absence. Attributs La classe Justification a les attributs suivants : 1. Identifiant : private 2. IdentifiantPublique : public 3. ÉtatJustification : public 4. URLJustification : public Rôle Complexité Son rôle est de sauvegarder et manipuler les données de l’entité Justification. Facile Table 3.15 : Fiche descriptive de la classe Justification CHAPITRE 3. CONCEPTION Nom de la classe Description Relations 61 Utilisateur Système C’est une classe abstraite des entités des utilisateurs du système (et non pas les administrateurs du système). Cette classe a : • Une relation d’association avec la classe Administrateur ; • Elle est dérivée de la classe Personne ; • Elle est la classe mère des classes : Étudiant et Enseignant. Attributs La classe Utilisateur Système a les attributs suivants : 1. Identifiant : private 2. IdentifiantPublique : public 3. IdentifiantCarte : public 4. PseudoUtilisateur : public 5. EmailUtilisateur : public 6. MotDePasseUtilisateur : public Rôle Son rôle est de définir la structure des données et le comportement en commun des entités des utilisateurs du système. Facile Complexité Table 3.16 : Fiche descriptive de la classe Utilisateur Système Nom de la classe Description Relations Attributs Demande de suppression Cette classe représente l’entité DemandeSuppression du système. Cette classe a 2 relations d’association avec les classes Administrateur et Enseignant. La classe Demande de suppression a les attributs suivants : 1. Identifiant : private 2. IdentifiantPublique : public 3. DateDemandeDeSuppression : public Rôle Complexité Son rôle est de sauvegarder et manipuler les données de l’entité DemandeSuppression. Facile Table 3.17 : Fiche descriptive de la classe Demande de suppression CHAPITRE 3. CONCEPTION Nom de la classe Description Relations 62 Section Cette classe représente l’entité Section du système. Cette classe a : • 2 relations d’agrégation avec les classes Spécialité et Groupe, la classe Section est l’agrégeant de la classe Spécialité et l’agrégé de la classe Groupe. Attributs La classe Section a les attributs suivants : 1. Identifiant : private 2. IdentifiantPublique : public 3. NomSection : public Rôle Complexité Son rôle est de sauvegarder et manipuler les données de l’entité Section. Facile Table 3.18 : Fiche descriptive de la classe Section Nom de la classe Description Relations ActionÉtudiantSéance Cette classe est une classe abstraite qui représente la relation entre l’étudiant et la séance. Cette classe : • Est une classe-association de la relation d’association Étudiant-Séance ; • Elle est la classe mère des deux classes Présence et Absence. Attributs La classe ActionÉtudiantSéance a les attributs suivants : • Identifiant : private • IdentifiantPublique : public • DateEtHeureAction : public Rôle Complexité Son rôle est de définir la structure des données et le comportement en commun des entités qui représente la relation entre l’étudiant et la séance (Présence et Absence). Facile Table 3.19 : Fiche descriptive de la classe ActionÉtudiantSéance CHAPITRE 3. CONCEPTION Nom de la classe Description Relations 63 Présence Cette classe représente l’entité Section du système. • Cette classe est dérivée de la classe ActionÉtudiantSéance ; • Une relation d’agrégation avec la classe Étudiant, elle est l’agrégeant. Attributs Rôle Complexité La classe Présence n’a aucun attribut de particulier, sauf les attributs qu’elle hérite de sa classe mère Son rôle est de sauvegarder et manipuler les données de l’entité Présence. Facile Table 3.20 : Fiche descriptive de la classe Présence Nom de la classe Description Relations Absence Cette classe représente l’entité Absence du système. • Cette classe est dérivée de la classe ActionÉtudiantSéance ; • Une relation d’agrégation avec la classe Étudiant, elle est l’agrégeant. Attributs Rôle Complexité La classe Absence n’a aucun attribut de particulier, sauf les attributs qu’elle hérite de sa classe mère Son rôle est de sauvegarder et manipuler les données de l’entité Absence. Facile Table 3.21 : Fiche descriptive de la classe Absence CHAPITRE 3. CONCEPTION 3.2.2 64 Diagramme de classes Après l’identification et la documentation des classes qui nous a permet d’avoir des informations sur les classes on peut dresser un diagramme qui représente la structure du futur système en utilisant le langage de modélisation UML. En UML, le diagramme de classe symbolise les classes du système par des rectangles qui contient des compartiments pour le nom de la classe, ses méthodes et leurs visibilités, ses attributs et leurs visibilités, le type de la classe (une classe abstraite est symbolisé par un nom de classe en italique) et un stéréotype définit par le concepteur qui indique la famille de la classe. La figure suivante représente le diagramme de classes conceptuelles du futur système : CHAPITRE 3. CONCEPTION Figure 3.1 : Diagramme de classes 65 CHAPITRE 3. CONCEPTION 3.3 3.3.1 66 Schéma et diagramme de la base de données : Schéma de la base de données Après l’élaboration du diagramme de classes, le concepteur doit fournir le schéma de la base de données avec un diagramme qui représente les différentes tables et leurs relations. Une base de données est une collection organisée de données stockées sur un support physique, elle permette le partage et l’accès multiple aux informations. Pour accéder aux informations stockées dans une base de données on utilise un Système de gestion de base de données (SGBD). Le SGBD nous permet d’interroger la base de données en utilisant un langage déclaratif afin d’avoir un résultat qui convient à la requête exécutée. Le concepteur doit penser à l’organisation des informations dans la base de données. Il existe plusieurs modèles d’organisation, on peut citer : le modèle hiérarchique, le modèle réseau, le modèle relationnel... Il existe aussi plusieurs systèmes de gestion de base de données, chaque SGBD implémente un modèle pour organiser les données. Le modèle implémenté par le SGBD doit être identique au modèle choisi par le concepteur. Pour passer du diagramme de classe vers le schéma de la base de données en modèle relationnel, il existe des règles de transformation qui sont appliquées aux classes et leurs relations. Le passage est conclu par un schéma de la base de données. Les règles de transformations : 1. Règle 1 : Présence de la cardinalité 1.. ? d’un côté d’une association • Chaque classe se transforme en une table. • Chaque attribut de la classe se transforme en un attribut de la table. • L’identifiant de la classe qui est associée à la cardinalité 1.. ? devient une clé étrangère de l’autre classe. 2. Règle 2 Présence de la cardinalité ?..* des deux côtés d’une association : • Chaque classe se transforme en une table. • Chaque attribut de la classe se transforme en un attribut de la table. • La classe-association se transforme en une table qui comporte deux clés étrangères des deux classes de la relation d’association avec la cardinalité ?..*. 3. Règle 3 Présence d’une relation de généralisation : • Méthode 1 : créer une table avec tous les attributs des classes et ajouter un attribut type pour repérer les types d’objets. • Méthode 2 : créer une table pour chaque classe dérivée, chaque table comporte les attributs en communs plus les attributs spécifiques. • Méthode 3 : créer une table par classe et définir des relations d’association entre ces tables. Le tableau suivant représente le schéma de la base de données : 11 12 13 14 15 7 8 9 10 6 4 5 3 1 2 N Table 3.22 : Schéma de la base de données Administrator (id, public id, user name, email, password) Student (id, public id, first name, last name, birthday, address, phone number, card id, user name, email, password, gender, group id*) Professor (id, public id, first name, last name, birthday, address, phone number, level, card id, user name, email, password, gender, department id*) Faculty (id, public id, name, short name, address, phone number) Department (id, public id, name, short name, address, phone number, faculty id*, head of department id*) Speciality (id, public id, name, short name, department id*, hed of department id*) Section (id, public id, name, speciality id*) Group (id, public id, name, section id*) Subject (id, public id, name, short name, speciality id*) Class (id, public id, class date, start time, end time, subject id*, professor id*, classroom id*, group id*) Complaint (id, public id, description, status, student id*) Presence (id, public id, student card id*, class id*) Justification (id, public id, status, URL, student id*, class id*) RemovalRequest (id, public id, request date, professor id*) Classroom (id, public id, name) Relation CHAPITRE 3. CONCEPTION 67 CHAPITRE 3. CONCEPTION 3.3.2 Diagramme de la base de données Pour modéliser le schéma de la base de données, on utilise un diagramme Enhanced entityrelationship (EER). Ce diagramme permet de présenter les entités du système (tables de la base de données), les attributs de ces entités et ses relations. La figure suivante représente le diagramme EER de la base de données du futur système : 68 CHAPITRE 3. CONCEPTION Figure 3.2 : Diagramme de la base de données 69 CHAPITRE 3. CONCEPTION 3.4 70 Scénario d’exécution La dernière étape de la phase de conception est la modélisation des scénarios d’exécution. Un scénario d’exécution est lié à un cas d’utilisation, il est modélisé par un diagramme d’activité qui représente l’enchaı̂nèrent des activités invoquées par les différents acteurs du cas d’utilisation et aussi les actions du système. L’avantage majeur du diagramme d’activité est l’illustration simple du processus par des organigrammes, cette représentation simple permet la comparaison facile entre des différents scénarios. Les figures suivantes représentent une illustration du scénario d’exécution des cas d’utilisation documentés dans le chapitre précédent : Figure 3.3 : Diagramme d’activité Ajouter un étudiant CHAPITRE 3. CONCEPTION Figure 3.4 : Diagramme d’activité Consulter le relevé d’absence 71 CHAPITRE 3. CONCEPTION Figure 3.5 : Diagramme d’activité Consulter les statistiques 72 CHAPITRE 3. CONCEPTION Figure 3.6 : Diagramme d’activité Faire l’appel 73 CHAPITRE 3. CONCEPTION Figure 3.7 : Diagramme d’activité Faire une réclamation 74 CHAPITRE 3. CONCEPTION Figure 3.8 : Diagramme d’activité Gérer les justifications 75 CHAPITRE 3. CONCEPTION Figure 3.9 : Diagramme d’activité Justifier une absence 76 CHAPITRE 3. CONCEPTION 3.5 77 Conclusion Dans ce chapitre, la structure générale du futur système a été conçue. Une documentation des classes été faite sous forme de fiches descriptives afin de donner des information sur la structure pour le but de dresser un diagramme de classes. En utilisant les fiches descriptives et les documentations du chapitre précédent, un diagramme de classes été dressé, ce diagramme représente les entités du futur système et les relations entre eux. Le résultat de cette étape est une illustration graphique de la structure générale du système. Le diagramme de classes n’est pas suffisant aux réalisateurs du projet pour commencer l’implémentation et la mise en place de la structure conçue, un schéma de base de données est indispensable. Via les règles de passages présentées dans ce chapitre, un schéma relationnel a été établi et illustré par un diagramme EER qui figure les tables de la base de données, les attributs et les différentes relations. Après le schéma de la base de données et le diagramme EER, les scénarios d’exécutions ont été modélisés afin d’illustrer l’enchaı̂nement des actions des acteurs pour chaque cas d’utilisation. La réalisation du projet peut maintenant commencer à l’aide des différents diagrammes et documentations établis dans cette étape. Chapitre 4 Implémentation 4.1 Introduction L’implémentation est l’avant-dernière activité du processus de développement unifié, elle consiste à utiliser les différents documentations et diagrammes établis dans les chapitres précédents et les traduire en code source dans le but de réaliser la solution conçue. Autrement dit, traduire les besoins des utilisateurs du système exprimés précédemment en solution livrable qui répond à ces besoins. L’activité de l’implémentation est l’activité la plus coûteuse en terme de temps par rapport aux autres activités du processus unifié. La solution proposée sera réalisée par des différents technologies, chaque technologie est intégrée en utilisant un environnement de développement et des outils spécifiés à cette dernière. Ce chapitre présente les différents technologies et comment ils sont intégrés dans la solution proposée. 4.2 Environnement de développement Les tableaux suivants représente la configuration matérielle utilisée dans l’implémentation de la solution conçue. Modèle CPU GPU RAM Stockage Système d’exploitation Lenovo ThinkPad X220 4291RW0 Intel i5-2520M (4) @ 3.200GHz Intel HD Graphics 8GB DDR3 HDD 320GB Debian GNU/Linux 10 (Buster) x86 64, noyau 4.19.0-10amd64 Table 4.1 : Spécifications techniques de l’ordinateur 1 78 CHAPITRE 4. IMPLÉMENTATION Modèle CPU GPU RAM Stockage Système d’exploitation 79 Dell Inspiron 3542 Intel core i5-4210U @ 1.70GHz Intel HD Graphics 8GB DDR3 HDD 1TB Windows 10 Table 4.2 : Spécifications techniques de l’ordinateur 2 4.3 Base de données Dans le chapitre précédent on a établi à travers les règles de transformation du diagramme de classes vers le modèle relationnel un tableau des relations de la base de données ainsi qu’un diagramme de base de données qui illustre les différents tableaux ses relations et ses attributs. À l’aide du diagramme et la documentation établis précédemment on peut mettre en place la base de données. Le système de gestion de base de données choisis pour ce projet est MariaDB. MariaDB est un système de gestion base de données gratuit et Open Source développé par la communauté. Ce SGBD est un fork de MySQL. MariaDB est disponible sur le site officiel https://mariadb.org/ et aussi sur les dépôts du Debian Buster . % apt - cache search mariadb - server mariadb - server - MariaDB database server ( metapackage depending on the latest ver mariadb - server -10.3 - MariaDB database server binaries mariadb - server - core -10.3 - MariaDB database core server files Le service de MariaDB doit être lancé en permanence pendant le processus de développement. $ sudo systemctl enable mariadb; $ sudo systemctl start mariadb; La version de MariaDB utilisé pendant le développement de l’application Web est la suivante : % mariadb -- version mariadb Ver 15.1 Distrib 10.3.23 - MariaDB , for debian - linux - gnu ( x86_64 ) using re Un outil d’administration de base de données est indispensable, il permet la création facile et rapide du schéma de la base de donnés et l’interaction efficace avec la base de donnée. Il permet aussi de générer le diagramme EER qui illustre les différents tables de la base de données, ses attributs et ses relations. L’outil d’administration de base de données utilisé pendant le développement de l’application Web est DBeaver . CHAPITRE 4. IMPLÉMENTATION Figure 4.1 : Universal Database Manager La figure suivante illustre l’interaction entre l’application Web et la base de données : Figure 4.2 : Interaction avec la base de données 80 CHAPITRE 4. IMPLÉMENTATION 4.4 81 Application Web Une application web et un programme persistant sauvegardé sur un serveur distant délivré sur un réseau (par exemple Internet), cette application est accessible par plusieurs utilisateurs en même temps à travers un navigateur. l’application Web sert comme une interface de gestion pour le système de gestion des absences de la faculté des nouvelles technologies de l’information et de la communication. L’interface de gestion délivre les informations aux utilisateurs via le protocole HTTP. HTTP est un protocole de la couche application du modèle OSI, son rôle est de distribuer les informations des ressources accessibles par l’utilisateur. La communication entre l’utilisateur et le serveur se fait à travers une session HTTP, c’est une série de transactions requête-réponse. Cette communication est appelée l’approche client-serveur. Figure 4.3 : L’architecture client-serveur. Quand l’utilisateur accède à l’application Web, le serveur interroge la base de données pour récupérer les données et les afficher. Le tableau suivant définit le langage de programmation, l’environnement de développement et le serveur de l’application Web. Langage de programmation Environnement de développement Serveur Java 11 compilé sur Debain 10 Buster IntellijIDEA ULTIMATE 2019.3 Tomcat 9.0.34 Table 4.3 : Environnement de développement de l’application Web CHAPITRE 4. IMPLÉMENTATION 4.4.1 82 Language de programmation Le langage de programmation utilisé pour développer l’application Web est le fameux langage basé sur le paradigme orienté-objet Java . L’édition standard de Java n’est pas suffisante pour développer une application Web, Jakarta EE (précédemment Java Enterprise Edition) est utilisé dans le but d’étendre l’édition standard de Java. Jakarta EE permet d’ajouter la possibilité de développement des applications hébergées sur un serveur. % java -- version openjdk 11.0.8 2020 -07 -14 OpenJDK Runtime Environment ( build 11.0.8+10 - post - Debian -1 deb10u1 ) OpenJDK 64 - Bit Server VM ( build 11.0.8+10 - post - Debian -1 deb10u1 , mixed mode , shari OpenJDK 11 est disponible sur les dépôts du Debian Buster 10 ou sur le site officiel https://openjdk.java.net/. % apt - cache search openjdk -11 - jdk default - jdk - Standard Java or Java compatible Development Kit default - jdk - headless - Standard Java or Java compatible Development Kit ( headless openjdk -11 - jdk - OpenJDK Development Kit ( JDK ) openjdk -11 - jdk - headless - OpenJDK Development Kit ( JDK ) ( headless ) Environnement de développement Les spécifications du matériel utilisé pour développer l’application mobile est cité précédemment dans ce chapitre. L’application Web est développé à l’aide d’un environment de développement intégré (IDE) fourni par JetBrains et disponible sur le site officiel https://www.jetbrains.com/frfr/idea/ . IntellijIDEA facilite la tache de développement car il permet l’intégration facile des projets Maven, le changement rapide entre des différents versions de la Runtime Java et du serveur qui héberge l’application. Figure 4.4 : JetBrains IntellijIDEA CHAPITRE 4. IMPLÉMENTATION 83 Maven Maven est un outil de gestion et d’automatisation de production des projets logiciels Java en général et Java EE en particulier. Il est utilisé pour automatiser l’intégration continue lors d’un développement de logiciel. Maven est géré par l’organisation Apache Software Foundation https://maven.apache.org/. L’application Web dépend d’autres projets (appelés aussi dependencies), Maven permet une intégration et une gestion facile de ces derniers. La figure suivante illustre les dépendances du projet Maven de l’application Web. Figure 4.5 : Dépendances du projet Maven Pour intégrer une dépendance à un projet Maven, il suffit de l’ajouter au ficher de configuration du projet appelé pom.xml. <dependencies> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.16</version> </dependency> </dependencies> La liste suivante définit en bref le rôle de chaque dépendance illustrée dans la figure 4.5 : • JUnit : un framework de test unitaire pour le langage de programmation Java, il permet le test du code avant l’intégration. • JSTL : la JavaServer Pages Standard Tag Library (JSTL) est un composant de la plateforme JEE de développement. Elle étend la spécification JSP en ajoutant une bibliothèque de balises. • servlet-api : permet de créer des contrôleurs. • mysql-connector-java : permet la connection avec une base de données MySQL. CHAPITRE 4. IMPLÉMENTATION 4.4.2 84 La structure du projet L’architecture MVC Model-View-Control (MVC) est un pattern de développement des applications Web basées sur le paradigme de programmation orienté-objet. Il permet une meilleure organisation du code source du projet et une compréhension du rôle de chaque ficher du code source. Le but de l’architecture MVC est de séparer la logique du code en trois parties : 1. Modèle : cette partie gère les données des entités de l’application. Son rôle et de maintenir les données récupérés de la base de données. Dans le code source, un modèle est une Classe Java. public class Model1 { public String user_name; private String password; public Model (String user_name, String password) { this.user_name = user_name; this.password = password; } } Figure 4.6 : Modèle 2. Vue : cette partie assure l’affichage des interfaces et des données récupérés de la base de données. Une vue dans le code source et un ficher HTML si le contenu est statique, ou un ficher JSP si le contenu est dynamique. <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>View1</title> </head> <body> <h1>Welcome to View1</h1> </body> </html> Figure 4.7 : Vue 3. Contrôleur : cette partie est le cerveau du code, elle assure le bon fonctionnement de la logique de l’application. En code source, un contrôleur est une Classe Java qui hérite ses fonctionnalité de la classe HttpServlet. En Jakarta EE , un contrôleur est appelé aussi une Servlet. CHAPITRE 4. IMPLÉMENTATION 85 public class Controller1 extends HttpServlet { // Logique du contr^ oleur } Figure 4.8 : Contrôleur Structure du projet • /src : Contient le code source du projet de l’application Web. • /pom.xml : Le ficher pom.xml définit la configuration et les dépendances du projet Maven. • /src/main/java : Contient la dossiers suivants : – Control : regroupe les classes de contrôle (appelées aussi emphServlets). – Model : regroupe les classes modèles. – Utils : regroupe des outils qui facilite la tâche de développement, par exemple les connecteurs de la base de données. • /src/main/java/Model/Abstract : Contient les classes abstraites utilisés dans la structure du système. • /src/test/java : contient les classes de teste utilisés pout valider les fonctionnalités ajoutées avant l’intégration. • /web/WEB-INF : contient les vues du l’architecture MVC (les différents fichiers HTML et JSP). • /web/web.xml : appelé aussi Deployment Descriptor est le ficher de configuration qui permet d’identifier les contrôleurs et configurer le projet pour le déploiement. Figure 4.9 : Structure du projet de l’application Web CHAPITRE 4. IMPLÉMENTATION 4.4.3 Captures de l’application Web Figure 4.10 : Capture 1 de l’application Web Figure 4.11 : Capture 2 de l’application Web 86 CHAPITRE 4. IMPLÉMENTATION Figure 4.12 : Capture 3 de l’application Web Figure 4.13 : Capture 4 de l’application Web 87 CHAPITRE 4. IMPLÉMENTATION 4.5 88 Appareil de prise de présences La solution proposée pour automatiser la tâche de la prise de présence dans la faculté des nouvelles technologies de l’information et de la communication est de concevoir et de réaliser un appareil électronique basée sur la carte de contrôle Raspberry PI et à l’aide de la technologie de la radio-identification. 4.5.1 Raspberry PI Raspberry Pi est un ordinateur minuscule qui fait les dimensions d’une carte de crédit, il est capable d’exécuter un système d’exploitation grâce à son microprocesseur de type ARM. Cette petite machine peut être branchée sur un moniteur et avec un clavier et une souris on peut l’utiliser comme un ordinateur de bureau pour surfer sur internet, faire des traitements de texte, apprendre à programmer. . . etc La première apparition de la Raspberry Pi était en Février 2012 en Royaume Unie, le but de la création de cet ordinateur et de l’intégrer dans les écoles des pays en développement pour enseigner les basiques de la science de l’informatique. Le projet de charité éducative crée par la Raspberry Pi Foundation a connu plusieurs utilisations autre que l’éducation. Il est largement exploité dans des projets IoT comme les maisons intelligentes (Smart Homes), les robotiques et la collecte de données dans plusieurs domaines (on peut citer : le domaine agro-alimentaire, la sécurité informatique ...etc). Figure 4.14 : Raspberry PI Zero CHAPITRE 4. IMPLÉMENTATION 89 Grâce aux caractéristiques de la Raspberry Pi et de sa portabilité, elle est devenue la carte de contrôle la plus utilisée pour la collecte des données. Il existe plusieurs générations de cette carte avec des différentes dimensions et caractéristiques, on peut citer : Modèle Raspberry Pi 2 Model B Caractéristiques • Microprocesseur Quad Core ARM • 1GB de RAM • 40 GPIO pins • 4 ports USB 2.0 • Stereo output • Port FULL HDMI Raspberry Pi 3 Model B+ • Microprocesseur Quad Core ARM • 1GB de RAM • Connectivité : – Double bande Wi-Fi 802.11ac – Bluetooth 4.2 – Gigabit Ethernet • 40 GPIO pins • 4 ports USB 2.0 • Stereo output • Port FULL HDMI Raspberry Pi Zero W v1.1 • Microprocesseur Single Core ARM • 512MB de RAM • Connectivité : – Wi-Fi 802.11 b/g/n – Bluetooth 4.1 • 40 GPIO pins • 1 port micro USB Table 4.4 : les versions de la Raspberry PI CHAPITRE 4. IMPLÉMENTATION 90 Pour accomplir la tâche de la collecte automatique des présences des étudiants, l’appareil électronique est réalisé en utilisant la carte de contrôle la moins puissante et la technologie de la technologie de la radio-identification. Le choix d’utilisation de la Raspberry Pi Zero v1.1 est idéal pour ce cas d’utilisation à cause de ses dimensions qui facilite l’intégration dans plusieurs endroits, et le grand nombre des ports GPIO offert par cette dernière qui permet de brancher tous les modules nécessaires pour le fonctionnement de l’appareil. Figure 4.15 : Dimensions de la Raspberry PI Configuration de la carte de contrôle La Raspberry Pi Zero v1.1 est capable de lancer un système d’exploitation. Généralement GNU/Linux est l’OS utilisé pour piloter la machine. La distribution GNU/Linux officielle supportée et fournie par la Raspberry Pi Foundation est Raspbian. Cette dernière est basée sur la distribution Debian 10 Buster sortie en Novembre 2019. Raspberry Pi Foundation offre trois variantes de la distribution Raspbian : 1. Raspbian Buster avec un environnement graphique et des logiciels recommandés préinstallés, l’image fait plus de 2 Go. 2. Raspbian Buster avec un environnement graphique seulement, l’image fait plus de 1 Go. 3. Raspbian Buster Lite sans interface graphique, l’image fait moins de 500 Mo. Dans ce projet, on utilise la troisième variante Raspbian Buster Lite. Cette distribution est très légère pour se lancer sur la Raspberry Pi la moins puissante avec un micro processeur mono-core et 512 Mo de mémoire vive. De plus, l’appareil de collecte de données réalisée ne nécessite pas un environnement graphique pour accomplir sa tâche. Par défaut, la carte de contrôle n’a pas un moyen de stockage de masse intégré. Pour que la Raspberry Pi puisse démarrer le système d’exploitation, une carte micro SD est ajoutée dans CHAPITRE 4. IMPLÉMENTATION 91 le lecteur de cartes intégré au niveau de la carte pour maintenir le système d’exploitation et les différents fichiers de configuration. L’installation du système d’exploitation sur la Raspberry Pi est particulière. La méthode d’installation diffère d’un système d’exploitation à un autre. • Pour Microsoft Windows, il est préférable d’utiliser le logiciel officiellement supporté par la fondation. Raspberry Pi Imager offre une interface graphique simple et facile à utiliser, il suffit de choisir la carte micro SD branchée sur le bon lecteur et le fichier de l’image de la distribution pour obtenir une carte SD bootable et prête à installer sur la carte de contrôle. • Pour GNU/Linux et Apple Mac OS , il est possible d’utiliser l’outil dd (aussi connu sous le nom de Data Duplicator ) pour créer une carte micro SD bootable et prête à utiliser sur une Raspberry Pi. La commande à utiliser est la suivante : \$ sudo dd if=/lien/vers/image/raspbian.img of=/dev/sdX bs=4M conv=fsync la Raspberry Pi est alimentée par un courant continue d’une tension électrique entre 4.75V et 5.25V. Une petite lampe LED intégrée clignotera pour indiquer le bon fonctionnement de la carte. Figure 4.16 : Raspberry PI détaillée CHAPITRE 4. IMPLÉMENTATION 92 La prochaine étape de configuration est d’accéder à l’invite de commandes (aussi connu par le shell) de la Raspberry Pi. Afin d’avoir accès au compte utilisateur de la carte on doit configurer la connexion au réseau local via le récepteur Wi-Fi intégré. Cette connexion est effectuée en ajoutant un fichier de configuration wpa supplicant.conf au dossier boot du système d’exploitation gravé sur la carte micro SD. # Création du dossier boot sur la machine locale \$ mkdir boot_raspberry; # Montage de la partition boot de la Raspberry Pi \$ sudo mount /dev/sdX ./boot_raspberry && cd ./boot_raspberry; # Création du fichier de configuration \$ echo ''' ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev update_config=1 network={ ssid="NomDuRéseauWiFi" psk="MotDePasseRéseau" key_mgmt=WPA-PSK } ''' > wpa_supplicant.conf Une fois la connection est effectuée avec succès, un serveur SSH doit être lancé sur la carte de contrôle. Secure Shell Secure Shell (SSH) est un protocole de la couche présentation du modèle TCP/IP, il permet la connexion à une machine distante avec la possibilité de la télé-exécution des commandes. Le système d’exploitation de la Raspberry PI utilise OpenSSH , une suite d’outils pour établir une connexion sécurisée basée sur le protocol SSH qui opère sur le port 22 de la machine. OpenSSH server est installé par défaut sur la Raspberry PI . Il suffit de l’activer par la création d’un fichier vide avec le nom ssh dans le dossier boot de la carte micro SD. # Création du dossier boot sur la machine locale \$ mkdir boot_raspberry; # Montage de la partition boot de la Raspberry Pi \$ sudo mount /dev/sdX ./boot_raspberry && cd ./boot_raspberry; # Création du fichier ssh \$ touch ssh Le résultat des étapes précédentes est une Raspberry PI connectée au réseau avec un serveur SSH qui marche en permanence. CHAPITRE 4. IMPLÉMENTATION 93 Connexion à une Raspberry PI Pour prendre le contrôle de la carte, on doit posséder 3 informations reliée à cette dernière : 1. Le nom d’utilisateur par défaut ; 2. Le mot de passe par défaut ; 3. L’adresse IP locale de la Raspberry PI . Le nom d’utilisateur et le mot de passe par défaut des cartes Raspberry PI sont présents sur le site officiel de la Raspberry Pi Fondation. Nom d’utilisateur Mot de passe pi raspberry Pour connaı̂tre l’adresse IP locale de la Raspberry Pi connectée au réseau, il existe plusieurs techniques. La méthode la plus efficaces est d’utiliser un logiciel d’exploration de réseau comme Nmap. Une simple commande qui prend en entrée l’adresse du réseau et le masque sous-réseau nous rend une liste des appareils connectés avec leurs adresses logiques, adresses physiques et le nom du fabricant (Raspberry Pi Foundation dans notre cas). \$ sudo nmap -sn 192.168.1.0/24 Nmap scan report for 192.168.1.0/24 Host is up (0.00051s latency). MAC Address : B8:27:EB:B2:D9:AC (Raspberry Pi Foundation) On peut aussi vérifier le statut du serveur SSH par l’analyse des ports sur l’adresses IP obtenue. Si le port 22 est ouvert, le serveur SSH est en état actif. \$ sudo nmap 192.168.1.0/24 Host is up (0.0033s latency). Not shown: 999 closed ports 22/tcp open ssh Après la configuration headless (sans brancher des équipements d’entrée/sortie extérieures comme un écran ou un clavier), la Raspberry Pi est prête à l’utilisation. La commande suivante permet d’accéder au shell de la carte de contrôle. \$ ssh -p 22 pi@192.168.1.105 Il faut noter que OpenSSH client doit être installé sur la machine locale. OpenSSH est disponible sur les dépots du Debian Buster 10 . \$ sudo apt install openssh-{server,client} CHAPITRE 4. IMPLÉMENTATION 94 Figure 4.17 : Connexion SSH à une Raspberry Pi Une fois qu’on a accès au shell de la Raspberry Pi il faut la mettre à jour, activer l’interface GPIO et installer les librairies nécessaires pour le fonctionnement de l’appareil. L’interface GPIO GPIO est une interface présente sur la carte de contrôle sous forme de 40 pins. Elle permet la connexion avec d’autres circuits et modules pour la réalisation de projets électroniques. Figure 4.18 : GPIO CHAPITRE 4. IMPLÉMENTATION 4.5.2 95 La technologie de radio-identification Afin d’identifier les étudiants et les enseignants dans le système, le choix a été porté sur la technologie de radio-identification Radio Frequency Identification (RFID). La technologie RFID utilise les champs électromagnétiques afin d’identifier des cartes ou des tags marchant sur la même fréquence du capteur. Les tags et les cartes RFID contiennent un émetteur/récepteur radio, ce dernier envoi une information au moment de son déclenchement par une pulsion électromagnétique d’un lecteur (module) RFID. L’information envoyée est généralement l’identifiant unique de la carte. Dans ce projet, le capteur utilisé pour lire les informations des tags et des cartes RFID est le RC522. Figure 4.19 : Module RFID-RC522 4.5.3 Conception de l’appareil La conception de l’appareil électronique est faite à l’aide d’un logiciel dédié à cette tâche appelé Fritzing disponible sur le site officiel https://fritzing.org/. Ce logiciel permet d’élaborer le schéma de branchement des différentes modules électroniques avec la carte de contrôle. Le matériel utilisé pour réaliser l’appareil électronique : • Une carte de contrôleRaspberry Pi Zero v1.1 • Des lampes LED ; • Des résistances ; • Une Breadboard ; • Un module RFID-RC522 ; • Des cables de connexion Jumper. CHAPITRE 4. IMPLÉMENTATION La figure suivante illustre le schéma de branchement de l’appareil électronique de prise de présences automatique : Figure 4.20 : Schéma de branchement 96 CHAPITRE 4. IMPLÉMENTATION 4.5.4 97 Communication avec la base de données La communication entre l’appareil électronique est la base de données conçue est mise en place dans les chapitres précédents est effectuée à travers un intermédiaire de communication appelé API. Qu’est ce qu’une API REST ? Une API est une séries de règles qui permet les programmes de se communiquer entre eux, le développeur crée le serveur et autorise les clients d’interroger et de communiquer avec ce dernier. Une API Representational State Transfer (REST) est aussi une série de règles qui définissent la façon de communication de l’API avec les clients. Dans une API REST une information est retournée lorsqu’une requête est faite vers un URL spécifié. La communication entre un client et une API est effectuée à travers un format de données universel appelé JavaScript Object Notation (JSON). { "user_name": "ouailderghal25", "email": "ouailderghal@gmail.com", "password": "SuperSecretPASSWORD25" } Figure 4.21 : Données en format JSON Chaque route de l’API REST accepte un ou plusieurs type de requêtes, ces types sont appelées des méthodes : Méthode GET POST PUT DELETE Description permet d’effectuer une opération de lecture sur le serveur afin d’avoir une information spécifique. permet de créer une nouvelle entité sur la base de données. permet de mettre à jour une entité sur la base de de données. permet de supprimer une entité sur la base de données. Table 4.5 : Les méthodes HTTP Chaque requête effectuée sur l’API REST possède un code de statut. Le tableau suivant représente la signification des codes courants : Code 200 201 403 404 501 Signification Succès OK. Entité crée avec succès. Accès limité. Contenu non disponible. Erreur du serveur. Table 4.6 : Les codes HTTP CHAPITRE 4. IMPLÉMENTATION 4.6 98 Le projet API REST Pour assurer la communication de l’appareil électronique avec la base de données, une API REST doit être mise en place. L’API REST est développée par le langage de programmation Python et la librairie Flask . Flask est un micro-framework qui permet la création des applications Web à travers le langage de programmation Python. La version du langage de programmation utilité pour développer l’API est la suivante : % python3 -- version Python 3.7.3 Les dépendances du projet de l’API REST sont : 1. Flask : permet de créer les différentes routes de l’API, retourner les réponses et convertir les dictionnaires de Python en objets JSON . 2. mysql-connector : assure la connexion entre l’API et la base de données. 3. uuid : permet de générer des identifiants uniques à la demande. 4. unittest : permet de tester le code avant l’intégration. Ce projet est développé à l’aide de l’éditeur de code Sublime Text https://www.sublimetext.com/. Les testes de l’API avant la mise en services sont faits à travers des différents méthodes : • En utilisant l’outil cURL, il permet d’effectuer des requêtes HTTP via la ligne de commande. • Par le module des testes unitaires unittest et le module requests qui permet l’interaction avec l’API en utilisant les requêtes HTTP. • A l’aide d’un logiciel dédié au teste des APIs, ce logiciel est Postman. Grace à son interface simple, il permet d’exécuter les requêtes HTTP d’une façon simple et efficace et de sauvegarder les résultats. Postman est disponible sur le site officiel https://www.postman.com/. Figure 4.22 : Architecture de communication CHAPITRE 4. IMPLÉMENTATION 4.7 99 Le projet de l’appareil de prise de présences Après l’établissement du schéma de branchement et la réalisation de l’appareil électronique, il est impératif de développer le cerveau de l’appareil. Le programme qui joue le rôle de cerveau permet de communiquer avec les modules connectés à la carte de contrôle et invoquer des actions définies par la logique du programme. L’enseignant doit déverrouiller l’appareil pour chaque séance ; cette mesure de sécurité est posée pour éviter le fonctionnement non nécessaire et les erreurs humaines. Quand l’appareil détecte la carte de l’enseignant, il se déverrouille en clignotant la lampe verte. Quand un étudiant introduit sa carte sur le lecteur, l’appareil vérifie s’il s’agit d’une carte valide. Si la carte n’est pas valide la lampe rouge se clignotera, sinon l’appareil enregistre la présence de l’étudiant en clignotant la lampe bleue. Pour éviter la manipulation extérieure l’appareil ne permet pas de sauvegarder une présence existante dans la base de données et aussi l’enseignant est capable de verrouiller et déverrouiller l’appareil dans la limite du temps de la séance. Le programme cerveau de l’appareil de prise de présence est développé en Python v3.7.3 et il dépends d’autres modules nécessaire pour effectuer la communication entre la carte de contrôle, les modules connectés et l’API développée et mise en place précédemment. Les dépendances du projet de l’Appareil de prise de présences sont : 1. mfrc522 : ce module permet de communiquer avec le module RFID-RC522 utilisé comme un lecteur de cartes et de tags. 2. requests : ce module permet d’effectuer des requêtes HTTP à l’API mise en place précédemment. 3. gpiozero : ce module permet de contrôler les lampes LED qui indique le statut de l’appareil. 4. GPIO : ce module permet la communication avec les ports GPIO de la Raspberry Pi . 5. JSON : ce module permet de gérer les objets JSON. 6. threading : ce module permet de créer et lancer des programmes en parallèle. 7. unittest : permet de tester le code avant l’intégration. Ce projet est développé avec l’éditeur de code Vim. Il est un éditeur de code robuste et puissant qui peut se lancer dans une session SSH car il ne nécessite pas une interface graphique.Vim est disponible sur les dépôts du Debain Buster et sur le site officiel https://www.vim.org/. La version de Vim utilisée est la suivante : % vim -- version | head -n 1 VIM - Vi IMproved 8.1 (2018 May 18 , compiled Jun 15 2019 16:41:15) CHAPITRE 4. IMPLÉMENTATION 100 Figure 4.23 : Éditeur de code Vim 4.8 Application mobile Il s’agit d’application conçue pour une grande partie de systèmes d’exploitation fiables par les Smartphones en se référant à un langage particulier à chacun d’eux. Ce mode d’application est accessible seulement sur les plateformes d’applications suivant ses particularités et ses formules. Ces plateformes retirent 25% du prix de vente pour une application native payante. Le développement de l’application mobile nécessite le recours à la mémoire du Smartphone sans omettre les options reliées au système d’exploitation en question. De cette façon, le résultat se résume dans l’aboutissement à des applications mobiles avec des fonctions plus professionnelles, développées et performantes au même niveau que les applications en HTML5/CSS3 et les applications hybrides. Le souci des applications mobile est que les utilisateurs doivent avoir un système d’exploitation mobile donné pour qu’ils puissent les utiliser. Pour assurer un usage plus exponentiel de ces applications mobiles, il faut penser à lancer la même application mobile compatible à tout système d’exploitation mobile. 4.8.1 Android Android est un système d’exploitation ouvert (Open Source) pour tablettes tactiles, terminaux mobiles et TV connectées. Il a été conçu en 2007, par la société Android, une startup rachetée par Google. C’est un système d’exploitation fondé sur un noyau Linux disponible grâce à une licence Apache. Android inclut tous les utilitaires requis par un constructeur pour le mettre en œuvre dans un téléphone portable. Il est proposé à tous les fabricants de téléphones mobiles pour faciliter son adoption. Il a été conçu pour intégrer les applications Google comme Gmail, Google Map, Google Agenda, Google Talk ou encore You Tube. Android est un système presque équivalent à IOS, tant en fonctionnalités qu’en applications. CHAPITRE 4. IMPLÉMENTATION 101 Là où Apple cherche la cohérence et la sécurité, Android offre plus de choix et de personnalisation. Pour développer une application mobile sur ce support, le langage de programmation utilisé sera Java. Le kit de développement ou SDK (Software Développement Kit) autrement dit les outils de développement utilisés seront le SDK Android. On peut également utiliser le langage C++ avec le NDK (Native Développement Kit). 4.8.2 L’historique des versions d’Android Le système de Google n’aurait pas connu un tel succès s’il était resté le même en six ans. C’est là que l’on voit la puissance d’un tel OS qui a su s’adapter aux besoins des utilisateurs à chaque version majeure et qui s’enrichit de nouveautés. Nom de code Apple pie Version 1.0 Honeycomb 3.x.x Lollipop 5.0 Caractéristiques Version connue uniquement ou presque des développeurs car c’est la version du SDK distribuée avant la sortie du premier téléphone Android Réservé aux tablettes tactiles et aux téléviseurs connectés16, cette mise à jour comprend de nombreux changements dans l’interface • Nouvelle interface / design (”Material design”) • Amélioration de la rapidité • Amélioration de la gestion de la batterie Table 4.7 : Quelques versions d’Android Les principaux composants de ce système sont : • Le noyau Linux : Android repose sur un noyau Linux (version 2.6) qui gère les services du système, comme la sécurité, la gestion de la mémoire et des processus, la pile réseau et les pilotes. Il agit également comme une couche d’abstraction entre le matériel et la pile logicielle. • Les bibliothèques : En interne, Android inclut un ensemble de bibliothèques C et C++ utilisées par de nombreux composants de la plateforme Android. • Moteur d’exécution Android : Chaque application Android s’exécute dans son propre processus, avec sa propre instance de machine virtuelle Dalvik. CHAPITRE 4. IMPLÉMENTATION 102 • Le Framework : Android offre aux développeurs la possibilité de créer des applications extrêmement riches et innovantes. • Applications : Android est fourni avec un ensemble d’applications natives permettant d’accéder à des fonctionnalités comme les courriels, le téléphone, le calendrier, les photos Ces applications sont développées à l’aide du langage de programmation Java. Pour l’utilisateur final, c’est la seule couche accessible et visible. Figure 4.24 : Architecture logicielle de l’Android 4.8.3 Environnement de développement Android Studio Depuis décembre 2014, l’environnement de développement Eclipse, avec son module ADT ont pris leur retraite afin de faire place au tout nouvel environnement Android Studio. Android Studio représente la plateforme officielle, soutenue par Google, pour le développement d’applications Android. Il repose sur IntelliJ (Community Edition) de JetBrain et devrait permettre aux développeurs d’être plus rapides et plus productifs. Il offre toutes les possibilités nécessaires pour développer une application Android complète. Android Studio est annoncé le 15 mai 2013 lors du Google I/O et une version ”Early Access Preview” est disponible le jour même. Le 8 décembre 2014, Android Studio passe de la version bêta à la version stable 1.0. Android Studio remplace alors Eclipse ADT en tant qu’IDE officiel. Le 7 avril 2016, la version v2.0 est centrée sur la performance. Elle introduit un émulateur beaucoup plus rapide et depuis le 19 CHAPITRE 4. IMPLÉMENTATION 103 septembre 2016, c’est la dernière version stable v2.2 Elle supporte Java 1.8, et améliore les performances globales. Dans ce projet on a choisi de travailler avec la version Android 4.0.1 (Beta 5). Figure 4.25 : Android Studio version 4.0.1 4.8.4 Communication avec la base de données La méthode la plus répondue de se connecter a une base de données MySQL à distance à partir d’une application mobile est de mettre une sorte de service au milieu. La façon la plus simple est d’écrire des Scripts en Java, Php, JavaScript . . . pour gérer la base de données en utilisant le protocole HTTP du système Android. Ce service est appelé API (Application Programming Interface). Dans notre projet on a développée cette dernière en JavaScript. Node.js Node.js est une plateforme logicielle libre en JavaScript orientée vers les applications réseaux événementielles hautement concurrentes qui doivent pouvoir monter en charge. Parmi les modules natifs de Node.js, on retrouve http qui permet le développement de serveur HTTP. On a ajouté plusieurs Middleware pour assurer la fiabilité de notre API. Ces Middleware sont les suivantes : • Express.js : est une infrastructure d’applications Web Node.js minimaliste et flexible qui fournit un ensemble de fonctionnalités robuste pour les applications Web et mobiles. API Grâce à une foule de méthodes utilitaires HTTP et de middleware mise à votre disposition, la création d’une API robuste est simple et rapide. • BodyParser.js : Analyser les corps de demande entrants dans un middleware avant vos gestionnaires, disponibles sous la propriété req.body . • md5 : permet de crypter mots de passe. • UUID : permet de générer des identifiants universels et unique. CHAPITRE 4. IMPLÉMENTATION 104 • MySQL : permet d’accéder à une base de données. • Multer : permet de télécharger un fichier. Gradle Gradle est un moteur de production (un logiciel dont la fonction principale consiste à automatiser l’ensemble des actions (préprocessing, compilation, éditions des liens, etc.) contribuant, à partir de données sources, à la production d’un ensemble logiciel opérationnel) fonctionnant sur la plateforme Java. Il permet de construire des projets en Java. On a ajouté plusieurs dépendances à l’aide du Gradle pour nous aider à construire notre application mobile. Ces dépendances sont : • androidx.appcompat :appcompat :1.2.0 : permet l’accès aux nouvelles API sur les anciennes versions API de la plate-forme. • androidx.constraintlayout :constraintlayout :1.1.3 : positionner les widgets d’une manière flexible avec un positionnement relatif. • androidx.recyclerview :recyclerview :1.1.0 : Affichez de grands ensembles de données dans votre interface utilisateur tout en minimisant l’utilisation de la mémoire. • com.android.volley :volley :1.1.1 : permet de récupérer la réponse à partir de l’API. • com.github.bumptech.glide :glide :4.11.0 : permet de récupérer l’URL d’une image placée dans un répertoire dans notre serveur et l’affichée. Figure 4.26 : Les dépendances de l’application mobile 4.8.5 La structure du projet Tout projet Android doit respecter une hiérarchie bien précise qui permettra au compilateur de retrouver les différents éléments et ressources lors de la génération de l’application. Cette hiérarchie favorise la modularité des applications Android. CHAPITRE 4. IMPLÉMENTATION 105 A la création du projet, Android Studio crée automatiquement des dossiers pour contenir les fichiers de code Java, les fichiers XML, et les fichiers multimédias. L’explorateur de projet nous permettra de naviguer dans ces dossiers. Ce projet a les caractéristique du modèle MVC car on a le package Activities qui représente les contrôleurs de notre application, Models représente le modèle et on trouve les vues dans le package Layout. On trouve l’URL de notre API dans le package API, les icônes et les images dans le package Drawable, le package Data a les classes qui nous aide à manipuler notre application. Ces classes sont : SharedPrefProfessor/SharedPrefStudent qui laisse l’utilisateur connecté, List Adapter permet de lister les éléments voulus. Le package Values contient les valeurs des couleurs, styles et strings. Figure 4.27 : La structure du projet Android CHAPITRE 4. IMPLÉMENTATION 4.8.6 Captures de l’application mobile Figure 4.28 : Capture 1 de l’application mobile 106 CHAPITRE 4. IMPLÉMENTATION Figure 4.29 : Capture 2 de l’application mobile 107 CHAPITRE 4. IMPLÉMENTATION Figure 4.30 : Capture 3 de l’application mobile 108 CHAPITRE 4. IMPLÉMENTATION 4.9 109 Conclusion Dans chapitre on a présentée l’environnement de développement et les technologies utilisés pour mettre en place le système conçu dans les chapitres précédents. On a présenté l’environnement de développement et les spécifications matérielles utilisés pour mettre en place le système d’information en question. Une application Web est mise en place pour permettre aux utilisateurs d’administrer le système ainsi qu’un appareil de prise de présences. Une application mobile est mise en place pour permettre aux utilisateurs d’accéder aux informations fournies par le système. Le résultat de ce chapitre est la solution proposée et conçue ultérieurement qui répond aux besoins des utilisateurs exprimés dans le cahier des charges. Chapitre 5 Conclusion générale Dans ce mémoire, on a présenté les différentes étapes et phases de développement d’un projet logiciel. Dans un premier temps on a élaboré une étude préliminaire, ensuite on a présenté l’architecture du système qui est le résultat de l’étape de conception et au final on a implémenté le système conçu à la base des différentes documentations établis dans les étapes précédentes. Le premier avantage du système conçu et mis en place est d’automatiser la tâche de prise de présences manuelle. Le système offre une interface de gestion qui permet aux administrateurs de mieux contrôler les séances pédagogiques. Il offre aussi une interface de visualisation des statistiques, cela permet aux gérants de la faculté de prendre des meilleures décisions. Le système peut être amélioré par : • L’intégration des technologies moins chers lors de la construction de l’appareil de prise de présences. • La transformation de l’appareil conçu et réalisé en un seul circuit sur une carte modulaire. • Rendre la communication entre les APIs et la base de données plus sécurisée en appliquant des technologies d’authentification. • Améliorer l’interface graphique de l’application mobile et du site web en appliquant les règles du design UI/UX. 110 Acronymes API Applicaition Programming Interface. 24, 96 BF besoin fonctionnel. 27 BNF besoin non-fonctionnel. 27 CDC cahier des charges. 22 CDCF cahier des charges fonctionnel. 22 CDCT cahier des charges technique. 22 DA diagramme d’activités. 16 DC diagramme de communication. 16 DCL diagramme de classes. 15 DCO diagramme de composants. 16 DCU Diagramme de cas d’utilisation. 29 DD diagramme de déploiement. 16 DET diagramme d’états-transitions. 16 DO diagramme d’objets. 16 DS diagramme de séquence. 16 EER Enhanced entity-relationship. 68 GPIO General Purpose Input/Output interface. 6, 93, 98 IDE environment de développement intégré. 82 JSON JavaScript Object Notation. 96, 98 JSTL JavaServer Pages Standard Tag Library. 83 MVC Model-View-Control. 84 111 Acronymes REST Representational State Transfer. 96 RFID Radio Frequency Identification. 94 SGBD Système de gestion de base de données. 66 SSH Secure Shell. 91 TIC Technologies de l’information et de la communication. 9 UP processus unifié. 17 112