|
Application web de gestion des licences des joueurs de football. Cas de la division provinciale des sports et loisirs de la Tshopopar Jyresse ILONGA ISP-Kisangani - Licence 2020 |
III.1. DIAGRAMME DE SEQUENCEL'objectif du diagramme de séquence est de représenter les interactions entre objets en indiquant la chronologie des échanges. Cette représentation peut se réaliser par cas d'utilisation en considérant les différents scénarios associés. Un diagramme de séquence se représente globalement dans un grand rectangle avec indication du nom du diagramme en haut à gauche.
a) Ligne de vie Une ligne de vie représente l'ensemble des opérations exécutées par un objet. Un message reçu par un objet déclenche l'exécution d'une opération. Le retour d'information peut être implicite (cas général) ou explicite à l'aide d'un message de retour. b) Message synchrone et asynchrone Dans un diagramme de séquence, deux types de messages peuvent être distingués :
Après l'étude des cas d'utilisation, nous avons pu dégager les diagrammes de séquences correspondants dont voici les plus importants :
· Diagramme de séquence du cas « Gestion de licences au secrétariat de la division » Figure n°3 : Diagramme de séquence : Gestion de licences au secrétariat de la division Commentaire : Lorsque l'utilisateur demande l'accès à l'application, il doit commencer d'abord à renseigner son nom d'utilisateur et son mot de passe via le serveur d'application qui prend en charge la vérification depuis la base de données. Si la base de données retrouve l'existence de ces identifiants, donc il y'aura l'accès au système et aux applications du menu correspondant. Sinon, le serveur d'application lui affiche un message d'erreur afin de rectifier ses données (ceci pour tous les utilisateurs). Après avoir effectué son authentification, il est sera afin autorisé d'exécuter ces différentes tâches, dont : l'enregistrement d'une licence, sa modification, sa suppression et ses affichages.
· Diagramme de séquence du cas « Gestion de licences au secrétariat de la division » Figure n°4 : Diagramme de séquence : Gestion de licences au secrétariat de la division Commentaire : Lorsque l'utilisateur demande l'accès à l'application, il doit commencer d'abord à renseigner son nom d'utilisateur et son mot de passe via le serveur d'application qui prend en charge la vérification depuis la base de données. Si la base de données retrouve l'existence de ces identifiants, donc il y'aura l'accès au système et aux applications du menu correspondant. Sinon, le serveur d'application lui affiche un message d'erreur afin de rectifier ses données (ceci pour tous les utilisateurs). Après avoir effectué son authentification, il est sera afin autorisé d'exécuter ces différentes tâches, dont : l'enregistrement d'une licence, sa modification, sa suppression et ses affichages. Ce diagramme est similaire à celui de la gestion de licences au secrétariat de la division.
· Diagramme de séquence du cas « Demande des licences au secrétariat de l'équipe » Figure n°5 : Diagramme de séquence : Demande des licences au secrétariat de l'équipe. Commentaire : Après authentification, il sera afin autorisé d'exécuter ces différentes tâches, dont : la demande des informations par rapport aux licences et leur affichage. · Diagramme de séquence du cas « Gestion affichage des licences à la présidence de l'équipe »
Figure n°6 : Diagramme de séquence : Gestion affichage des licences à la présidence de l'équipe Commentaire : Après authentification, il exécute ces différentes tâches, dont : la demande des informations par rapport aux licences et leur affichage. · Diagramme de séquence du cas « Gestion d'affichage des licences à la présidence de l'attente »
Figure n°7 : Diagramme de séquence : Gestion affichage des licences à la présidence de l'équipe Commentaire : Après authentification, il exécute ces différentes tâches, dont : la demande des informations par rapport aux licences et leur affichage. III.2. DIAGRAMME D'ACTIVITE Un cas d'utilisation montre ce que fait ou doit faire le système. Un diagramme d'activité permet de spécifier comment le système accomplit les fonctionnalités demandées. Un diagramme d'activité montre les actions à un très haut niveau d'abstraction avec les interactions entre elles. Dans la pratique, les diagrammes d'activité sont bien adaptés à cette phase de l'analyse qui consiste en l'expression des processus métier comme un ensemble d'actions coordonnées pour atteindre un but. Les concepts communs ou très proches entre le diagramme d'activité et le diagramme d'état-transition sont :
Le formalisme reste identique pour ces noeuds de contrôle. Les concepts spécifiques au diagramme d'activité sont :
Action Une action correspond à un traitement qui modifie l'état du système. Cette action peut être appréhendée soit à un niveau élémentaire proche d'une instruction en termes de programmation soit à un niveau plus global correspondant à une ou plusieurs opérations. Formalisme
Une action est représentée par un rectangle dont les coins sont arrondis comme pour les états du diagramme d'état-transition. Transition et flot de contrôle Dès qu'une action est achevée, une transition automatique est déclenchée vers l'action suivante. Il n'y a donc pas d'événement associé à la transition. L'enchaînement des actions constitue le flot de contrôle. Formalisme Le formalisme de représentation d'une transition est la suivante.
Activité Une activité représente le comportement d'une partie du système en termes d'actions et de transitions. Une activité est composée de trois types de noeuds :
Une activité peut recevoir des paramètres en entrée et en produire en sortie.
Formalisme Noeud de bifurcation (fourche) Un noeud de bifurcation (fourche) permet à partir d'un flot unique entrant de créer plusieurs flots concurrents en sortie de la barre de synchronisation. Noeud de jonction (synchronisation) Un noeud de jonction (synchronisation) permet, à partir de plusieurs flots concurrents en entrée de la synchronisation, de produire un flot unique sortant. Le noeud de jonction est le symétrique du noeud de bifurcation. Noeud de test-décision Un noeud de test-décision permet de faire un choix entre plusieurs flots sortants en fonction des conditions de garde de chaque flot. Un noeud de test-décision n'a qu'un seul flot en entrée. On peut aussi utiliser seulement deux flots de sortie : le premier correspondant à la condition vérifiée et l'autre traitant le cas sinon. Noeud de fusion-test Un noeud de fusion-test permet d'avoir plusieurs flots entrants possibles et un seul flot sortant. Le flot sortant est donc exécuté dès qu'un des flots entrants est activé. Présentation graphique du Diagramme d'Activités
Passer une demande Réception de la licence
Affichage de la licence Vérification de la demande
Livraison de la licence Validation de la licence Actualisation de la licence Vérification de la demande
CHAPITRE QUATRE : ELABORATION DU NOUVEAU SYSTEME D'INFORMATION IV.1. DIAGRAMME DE CLASSE Le diagramme de classe permet de donner la représentation statique du système à développer. Cette représentation est centrée sur les concepts de classe et d'association. Chaque classe se décrit par les données et les traitements dont elle est responsable pour elle-même et vis-à-vis des autres classes. Les traitements sont matérialisés par des opérations. La description du diagramme de classe est fondée sur :
a. Objet Nous allons donner une première définition du concept d'objet avant de traiter le concept de classe. La description d'un objet sera complétée simultanément à la présentation du concept de classe. Un objet est un concept, une abstraction ou une chose qui a un sens dans le contexte du système à modéliser. Chaque objet a une identité et peut être distingué des autres sans considérer a priori les valeurs de ses propriétés. b. Classe, attribut et opération § Classe Une classe décrit un groupe d'objets ayant les mêmes propriétés (attributs), un même comportement (opérations), et une sémantique commune (domaine de définition). Un objet est une instance d'une classe. La classe représente l'abstraction de ses objets. Au niveau de l'implémentation, c'est-à-dire au cours de l'exécution d'un programme, l'identificateur d'un objet correspond une adresse mémoire. Formalisme Une classe se représente à l'aide d'un rectangle comportant trois compartiments. Les trois compartiments de base sont : · La désignation de la classe, · La description des attributs, · La description des opérations.
§ Attribut Un attribut est une propriété élémentaire d'une classe. Pour chaque objet d'une classe, l'attribut prend une valeur.
Formalisme Caractéristiques Le nom de la classe peut être qualifié par un « stéréotype ». La description complète des attributs d'une classe comporte un certain nombre de caractéristiques qui doivent respecter le formalisme suivant :
- Visibilité : se reporter aux explications données plus loin sur ce point. - Nom d'attribut : nom unique dans sa classe. - Type : type primitif (entier, chaîne de caractères...) dépendant des types disponibles dans le langage d'implémentation ou type classe matérialisant un lien avec une autre classe. § Opération Une opération est une fonction applicable aux objets d'une classe. Une opération permet de décrire le comportement d'un objet. Une méthode est l'implémentation d'une opération.
Formalisme Caractéristiques La description complète des opérations d'une classe comporte un certain nombre de caractéristiques qui doivent respecter le formalisme suivant : · Visibilité Nom d'opération (paramètres) - Visibilité : se reporter aux explications données plus loin sur ce point. - Nom d'opération : utiliser un verbe représentant l'action à réaliser. - Paramètres : liste de paramètres (chaque paramètre peut être décrit, en plus de son nom, par son type et sa valeur par défaut). L'absence de paramètre est indiquée par ( ). - Type résultat : type de (s) valeur(s) retourné(s) dépendant des types disponibles dans le langage d'implémentation. Par défaut, une opération ne retourne pas de valeur. · Visibilité des attributs et opérations Chaque attribut ou opération d'une classe peut être de type public, protégé, privé ou paquetage. Les symboles + (public), # (protégé), - (privé) et ~ (paquetage) sont indiqués devant chaque attribut ou opération pour signifier le type de visibilité autorisé pour les autres classes. Les droits associés à chaque niveau de confidentialité sont :
Représentation graphique du diagramme de classes
1 1 Créer
1..* 1 Etablir 1..* 1..* 1 Afficher Afficher 1
1..* Afficher 1 1 1..* Afficher 1..*
IV.3. Implémentation du Nouveau système d'information Cette phase correspond à la production du logiciel sous forme de composants, de bibliothèques ou de fichiers. Cette phase reste, comme dans toutes les autres méthodes, la plus lourde en charge par rapport à l'ensemble des autres phases. a. Implémentation de la Base de Données Il est possible de traduire un diagramme de classe en modèle relationnel. Bien entendu, les méthodes des classes ne sont pas traduites. Cependant, dans le sens d'avoir respecté une méthodologie adaptée, la correspondance entre le modèle objet et le modèle relationnel n'est pas une tâche facile. En effet, elle ne peut que rarement être complète puisque l'expressivité d'un diagramme de classes est bien plus grande que celle d'un schéma relationnel. Par exemple, comment représenter dans un schéma relationnel des notions comme la navigabilité ou la composition ? Toutefois, de nombreux AGL (Atelier de Génie Logiciel) comportent maintenant des fonctionnalités de traduction en SQL qui peuvent aider le développeur dans cette tâche. c) Règles de passage d'un diagramme de classe vers un modèle relationnelDans notre projet, nous avons adapté les règles suivantes pour faire le passage du diagramme de classe vers le modèle relationnel. Ø Classe avec attributsChaque classe devient une relation. Les attributs de la classe deviennent des attributs de la relation. Si la classe possède un identifiant, il devient la clé primaire de la relation, sinon, il faut ajouter une clé primaire arbitraire. Pour représenter une association 1 vers 1 entre deux relations, la clé primaire de l'une des relations doit figurer comme clé étrangère dans l'autre relation. e) Une association 1 vers plusieurs Pour représenter une association 1 vers plusieurs, on procède comme pour une association 1 vers 1, excepté que c'est forcément la relation du côté plusieurs qui reçoit comme clé étrangère la clé primaire de la relation du côté. f) Association plusieurs vers plusieurs Pour représenter une association du type plusieurs vers plusieurs, il faut introduire une nouvelle relation dont les attributs sont les clés primaires des relations en association et dont la clé primaire est la concaténation de ces deux attributs. g) Classe Association plusieurs vers plusieurs Le cas est proche de celui d'une association plusieurs vers plusieurs, les attributs de la classe-association étant ajoutés à la troisième relation qui représente, cette fois-ci, la classe-association elle-même. h) Pour la généralisation (héritage) Les relations correspondant aux sous-classes ont comme clés étrangère et primaire la clé de la relation correspondant à la classe parente. Un attribut type est ajouté dans la relation correspondant à la classe parente. Cet attribut permet de savoir si les informations d'un t-uplet de la relation correspondant à la classe parente peuvent être complétées par un t-uplet de l'une des relations correspondant à une sous-classe, et, le cas échéant, de quelle relation il s'agit. Ainsi, dans cette solution, un objet peut avoir ses attributs répartis dans plusieurs relations. Il faut donc opérer des jointures pour reconstituer un objet. L'attribut type de la relation correspondant à la classe parente doit indiquer quelles jointures faire81(*). Schéma relationnel CREATE TABLE IF NOT EXISTS `joueurs` ( `ID` int(11) NOT NULL AUTO_INCREMENT, `EQACTUELE` varchar(35) NOT NULL, `EQPROVENANCE` varchar(35) NOT NULL, `NOM` varchar(25) NOT NULL, `POSTNOM` int(25) NOT NULL, `PRENOM` varchar(25) NOT NULL, `GENRE` varchar(15) NOT NULL, `NATIONALITE` varchar(35) NOT NULL, `LIEUNAISSANCE` varchar(30) NOT NULL, `DATENAISSANCE` varchar(15) NOT NULL, `TYPETRANSFERT` varchar(45) NOT NULL, `DUREETRANSFERT` varchar(10) NOT NULL, `PHOTOJOUEUR` varchar(50) NOT NULL, PRIMARY KEY (`ID`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; CREATE TABLE IF NOT EXISTS `licences` ( `ID` int(11) NOT NULL AUTO_INCREMENT, `EQACTUELE` varchar(45) NOT NULL, `EQPROVENANCE` varchar(45) NOT NULL, `NOM` varchar(25) NOT NULL, `POSTNOM` varchar(25) NOT NULL, `PRENOM` varchar(25) NOT NULL, `GENRE` varchar(15) NOT NULL, `NATIONALITE` varchar(45) NOT NULL, `LIEUNAISSANCE` varchar(45) NOT NULL, `DATENAISSANCE` varchar(15) NOT NULL, `TYPETRANSFERT` varchar(45) NOT NULL, `DUREETRANSFERT` varchar(15) NOT NULL, `DATEOCTROILICENCE` varchar(15) NOT NULL, `PHOTOJOUEUR` varchar(50) NOT NULL, PRIMARY KEY (`ID`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; CREATE TABLE IF NOT EXISTS `utilisateurs` ( `ID` int(11) NOT NULL AUTO_INCREMENT, `NOM` varchar(25) NOT NULL, `POSTNOM` varchar(25) NOT NULL, `PRENOM` varchar(25) NOT NULL, `GENRE` varchar(15) NOT NULL, `FONCTION` varchar(50) NOT NULL, `EQUIPE` varchar(45) NOT NULL, `NOMUTILISATEUR` varchar(20) NOT NULL, `MOTPASSSE` varchar(20) NOT NULL, PRIMARY KEY (`ID`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=3 ; Représentation graphique du schéma relationnel
1 1 Créer
1..* 1 Etablir 1..* 1..* 1 Afficher Afficher 1
1..* Afficher 1 1 1..* Afficher 1..*
IV.4. Diagramme de déploiement Le diagramme de déploiement permet de représenter l'architecture physique supportant l'exploitation du système. Cette architecture comprend des noeuds correspondant aux supports physiques (serveurs, routeurs...) ainsi que la répartition des artefacts logiciels (bibliothèques, exécutables...) sur ces noeuds. C'est un véritable réseau constitué de noeuds et de connexions entre ces noeuds qui modélise cette architecture. § Noeud Un noeud correspond à une ressource matérielle de traitement sur laquelle des artefacts seront mis en oeuvre pour l'exploitation du système. Les noeuds peuvent être interconnectés pour former un réseau d'éléments physiques. Formalisme
Un noeud ou une instance de noeud se représente par un cube ou parallélépipède § Artefact Un artefact est la spécification d'un élément physique qui est utilisé ou produit par le processus de développement du logiciel ou par le déploiement du système. C'est donc un élément concret comme par exemple : un fichier, un exécutable ou une table d'une base de données. Un artefact peut être relié à d'autres artefacts par notamment des liens de dépendance. Formalisme Un artefact se représente par un rectangle caractérisé par le mot-clé « artifact » et/ou une icône particulière dans le coin droit du rectangle.
L'architecture à deux niveaux (aussi appelée architecture 2-tiers, tiers signifiant étages en anglais) caractérise les systèmes clients/serveurs dans lesquels le client demande une ressource et le serveur la lui fournit directement. Cela signifie que le serveur ne fait pas appel à une autre application afin de fournir le service.
Représentation graphique du diagramme de déploiement
IV.5. PRESENTATION DES INTERFACES a) Connexion
b) Menu secrétaire de l'équipe
c) Menu chef de division
CONCLUSION GENERALE Nous voici au terme de notre travail de fin d'études qui a porté sur « Conception et réalisation d'une application web pour la gestion de licences des joueurs de football. Cas de la Division Provinciale de Sports et Loisirs de la Tshopo » de 2019 à 2020. En effet, nous avons démontré tout au long du travail que la gestion manuelle peut être remplacée en presque 95% (selon nos estimations) par une gestion automatisée offrant beaucoup de possibilités et d'avantages grâce à l'usage de l'outil de gestion automatique, rapide et fiable d'une masse d'information appelé « Ordinateur ». Sachant que toute recherche scientifique a comme objectif d'aboutir à un résultat, dans ce travail, nous nous sommes fixés les objectifs, ceux de s'imprégner du système d'information utilisé à la Division Provinciale des Sports et Loisirs de la Tshopo pour la gestion des licences de joueurs; et mettre en place une application web bien adaptée pour la gestion des licences des joueurs de football afin d'améliorer la qualité et la condition de travail de ces services. Pour y arriver, nous avons subdivisé notre travail en quatre chapitres : · Chapitre un : Considérations générales · Chapitre deux : Spécification des besoins et étude de faisabilité · Chapitre trois : Modélisation du système d'information · Chapitre quatre : Elaboration du nouveau système d'information Ainsi, nous nous sommes posé deux questions majeures pour poursuivre notre étude : Ø Le système manuel qu'utilise la Division Provinciale des Sports et Loisirs de la Tshopo pour la gestion des licences des joueurs des équipes de football est-il rassurant, sécurisé ou encore fiable pour ladite gestion ? Ø La conception et réalisation d'une application web serait-elle une solution optimale pour remédier aux problèmes que présente le système actuellement utilisé au sein de service de gestion des licences des joueurs à la Division Provinciale de Sports et Loisirs de la Tshopo ?
Dans l'enchaînement de notre réflexion, nous avons proposé comme hypothèses : Ø Le système manuel qu'utilise la Division Provinciale des Sports et Loirs de la Tshopo pour la gestion des licences des joueurs des équipes de football ne serait pas rassurant, sécurisé ou encore fiable pour ladite gestion d'autant plus qu'il présente beaucoup des failles telles que citées au niveau de la problématique ; Ø La conception et réalisation d'une application web serait une solution optimale pour remédier aux problèmes que présente le système actuellement utilisé au sein de service de gestion des licences des joueurs à la Division Provinciale de Sports et Loisirs de la Tshopo car cette dernier est mini des plusieurs avantages tels que : la sécurité, la rapidité, la confidentialité, fiabilité et bien d'autres mesures importantes. Pour vérifier nos hypothèses et aboutir à des résultats escomptés, nous nous sommes servi des méthodes telles que : méthode historique, structuro-fonctionnelle et UP, ainsi que les techniques documentaire, d'observation et d'interview. La présentation structurelle de ce programme est traduite par guide d'utilisation explicite. Nous pouvons dire que cette dernière partie concrétise notre travail. L'informatique devient un support de connaissances de l'humanité, aux fins de leur traitement, leur conservation dans le temps et de leur communication dans l'espace ; c'est ainsi que l'informatique bouscule les habitudes dans l'organisation, impose ses règles et finit par devenir un incontournable outil de gestion rationnelle, moderne de l'entreprise. Cependant, pour le traitement des données, il suffit de faire entrer les données et, le programme conçu dans l'ordinateur vous retourne toutes les solutions dans quelques minutes selon votre demande. La concrétisation de notre étude a abouti à la mise sur pied d'une application web qui a été capable de produire les états ci-après : - Les licences des joueurs par équipe ; - Liste de tous les joueurs ; - Licence d'un joueur. Eu regard à ce qui précède, nous disons que nos hypothèses préalablement établies sont confirmées et rencontrent les objectifs que nous nous sommes fixés. Nous pensons avoir mis un nouvel outil de travail pour une gestion efficace de licences à la Division Provinciale des Sports et Loisirs de la Tshopo. Nous demandons ainsi à nos potentiels lecteurs l'indulgence pour les insuffisances qu'ils auront à constater, étant donné que l'oeuvre humaine ne manque jamais d'imperfections, surtout que nous sommes à notre premier exercice intellectuel. En définitif, nous interpellons toutes les entreprises, de tous les secteurs, d'y prendre rendez-vous avec assiduité et à tous les chercheurs de s'y mettre avec coeur car n'ayant pas tout épuisé.
- DUHAMEI, Stratégie et direction de l'entreprise. (CLE)-27bd de port loyal-775013, Paris, 1986, p.31. - REZSOHAZY R., Théorie et critique des faits sociaux, la renaissance du livre, Bruxelles, 1971, p.68. - DJUNGU A.O., Outils et langages du web n.0, Kinshasa, MEDIASPAUL, 2013, p.10. - DJUNGU A.O., Intelligence Artificielle, Kinshasa, MEDIASPAUL, 2011, p.23.
- MUSAFIRI G., Notes de cours de MAI 1, 2017, cours inédit G2 Info, ISP/Kisangani. - BAKA LEKA Brejnev, Notes de cours de Programmation Orientée Objet (PHP), 2016, cours inédit G2 Info, ISP/Kisangani. - Germain MUSAFIRI U., Notes de cours de M.A.I 1, cours inédit, G2 Info, ISP/Kisangani, 2017 - 2018. - KAFUNDA P., Notes de cours d'Algorithme II, 2018, cours inédit, ISP/Kisangani. - KIKUNI Joseph, Laboratoire Informatique II, 2016, cours inédit G2 Info, ISP/Kisangani. - LONGOLI P., Notes de cours de management, G2 Info, ISP/Kisangani, 2019 - 2020. - MBISAMULO F., Notes de cours de Séminaire Informatique, 2017, cours inédit G3 IG, ISP/Kisangani. - MUSANGU L., Notes de cours de MAI 1, G2 IG, ISP-KIS, 2016-2017. - MUSANGU M., Notes de cours de langage HTML, cours inédit G2 Info, ISP/Kisangani, 2016. - MUSANGU M., Notes de cours de Structure des Ordinateurs, cours inédit G2 Info, ISP/Kisangani, 2016. - VITAMARA M., Initiation à la recherche scientifique, cours inédit, G2 Info, ISP/Kisangani, 2015 - 2016. - YAYA, Notes de cours de comptabilité analytique, G2 Info, ISP/Kisangani, 2015 - 2016. - LUKULU, Notes de cours de la recherche opérationnelle, L1 Info, ISP/Kisangani, 2018 - 2019.
- Guy LOMBAYA, Conception et réalisation d'une application 2-tiers pour la gestion des diplômes des étudiants. Cas de l' ISC-BENI, TFC Inédit, ISC-BENI, BENI, 2015 - 2016. - Gislain KIYOMBO, Automatisation de processus d'octroi des brevets de formation dans un centre de formation des modules informatiques ». Cas de Maison MADY SERVICE de Kisangani, TFC inédit, ISC-KIS, 2014 - 2015. - KIKUNI MALISAWA, J, Mise en oeuvre d'un système de gestion automatisée pour la gestion de contrôle des impôts, cas de la DGI NORD KIVU, TFC inédit, ISP/Gombe, 2010-2013. - MUSAFIRI G., Conception et réalisation d'une application web pour la gestion de vente des pagnes. Cas de la SOTEXKI, TFC inédit, ISP-Kisangani, 2015 - 2016 - MUSAFIRI G., Conception et réalisation d'une base de données pour la gestion de logement des clients dans un hôtel, cas de l'Hôtel SOTEXKI, TFC Inédit, ISP/Kisangani, 2013 - 2014. - NDJOLO P., Conception et réalisation d'une base de données pour la gestion de vente de médicaments dans des dépôts pharmaceutiques. Cas du dépôt SHIKINA/KISANGANI, TFC Inédit, ISP-KISANGANI, 2016 - 2017
- http://www.memoireonline/07/13/4787/m, conception-et-realisation-dune-base-de-données-pour-la-gestion-de-vente-des-produits-en-ligne-09.html, consulté le 12 novembre 2019 - http://www.systèmeinformation.org/fr/libray/517 azek.aspx, consulté le 23/12/2019 - http://www.systèmeinformation.org/fr/libray/517 azek.aspx, consulté le 23/12/2019 - http://www.systèmeinformatique.org/fr/libray/517 azetek.aspx, consulté le 23/12/2019 - http://www.sortesbasededonnées.org/fr/libray, consulté le 23/12/2019 - http://www.utilitébasededonnées.org/fr/libray, consulté le 23 décembre 2017 - https://www.wikipedia.com, consulté le 14/12/2019 - http://www.wikipédia.org/serveur_apacheHHTPserver/winr123nh/wiki, consulté le 29 décembre 2019 - http://www.wikipédia.org/serveur_microsoftinternetserver/winr124nh/wiki, consulté le 29 décembre 2019 - http://www.wikipédia.org/réseauxinformatiques/winf23, consulté le 09/02/2020 - http://www.wikipédia.org/protocalederéseaux/wini23, consulté le 10/02/2020 - http://www.openclassroom.org/lessitesweb_dynamique/wid2345, consulté le 10/02/2020 - http://www.openclassroom.org/lessitesweb_statique/wid2655, consulté le 10/02/2020 - http://www.wikipédia.org/langagewebaphp/zniw23, consulté le 10/02/2020 - http://www.wikipédia.org/langagewebjavascript/winz12, consulté le 10/02/2020 - www.openclassroom.net, consulté le 13/02/2020 - www.commentçamarche.net, consulté le 13/02/2020 - www.google.com, consulté le 13/02/2020 - http://www.wikipédia.org/systèmedinformations/wiki, consulté le 05/01/2020
- Le petit Larousse de poche, 2010 - Le Grand Robert, version électronique, Edition 2011
* 81Laurent Audibert, developpez.com/Cours-UML,06/03/2020 : 20h11' |
|
