Soutenance mémoire
Les avantages de l’architecture client/seveur
ARCHITECTURE GLOBALE
Afin de réussir l’étape de conception, il est nécessaire de suivre un contexte conceptuel qui répond aux spécificités et aux besoins fondamentaux de l’application, menant ainsi à la satisfaction des utilisateurs.L’architecture client/serveur est l’architecture qui paraît le mieux adapté à notre application. Nous allons entamer cette partie par la définition de cette architecture.
Présentation de l’architecture client/serveur
Cette architecture est basée sur l’utilisation de deux types de logiciels, à savoir un logiciel serveur et un logiciel client s’exécutant normalement sur deux machines différentes. On appelle logiciel serveur un programme qui offre un service sur le réseau. Le serveur accepte des requêtes, les traite et renvoie le résultat au demandeur. On appelle logiciel client un programme qui utilise le service offert par un serveur. Le client envoie une requête et reçoit la réponse. La seule obligation du coopération entre le client et le serveur est le respect du protocole qui assure la communication inter-processus : HTTP pour le Web, POP/IMAP/SMTP pour le courrier électronique, SNMP pour l’administration de réseau.
Les avantages de l’architecture client/seveur
Pourledéveloppementdenotreapplicationnousavonsoptépourl’architectureclient/serveur pour plusieurs raisons à savoir : • Modèle adéquat pour la distribution des données. • Prend avantage des fonctionnalités réseaux. • Facile d’ajouter des serveurs supplémentaires ou de mettre à jour les serveurs existants. • intégrité:lesdonnéesduserveursontgéréessurleserveurdefaçoncentralisée.Lesclients restent individuels et indépendants. • Partage des ressources : un serveur traite plusieurs clients en même temps et contrôle leurs accès aux ressources.
Conception détaillée
Dans ce qui suit, nous détaillons la conception à l’aide de la méthodologie UML.
Vue statique
Diagramme de classes
Le diagramme de classes exprime la structure statique du système en termes de classes et de relations entre ces classes. Il fait abstraction des aspects dynamiques et temporels. La figure 3.2 montre le diagramme de classes qui collaborent au fonctionnement de notre application.Ces classes sont decrites comme suit : • La classe Administrateur : Cette classe a comme attributsla clé primaire qui identifie l’administrateur (ref_Administrateur : Int), le login (login : String) et le mot de passe (motpasse : String). L’administrateur doit s’authentifier pour pouvoir consulter, modifier, ajouter ou supprimer une offre. • La classe Recruteur : Cette classe a comme attributs la clé primaire qui identifie le recruteur (ref_recruteur : Int), le nom et le prénom (nomprenom : string), le login (login : String) et le mot de passe (motpasse : String). Le recruteur doit s’authentifier pour pouvoir consulter la liste des demandes d’emploi. • La classe Candidat : Cette classe a comme attributs la clé primaire qui identifie le candidat (ref_candidat : Int), le nom et le prénom (nomprenom : string), l’adresse (adresse : String), le login (login : String) et le mot de passe (motpasse : String). • La classe Demande : Cette classe a comme attributs la clé primaire qui identifie la demande (ref_demande : Int), la date de la demande, les connaissances du candidat, etc. • La classe Offre : Cette classe a comme attributs la clé primaire qui identifie l’offre de l’emploi (ref_emploi : Int), la date de l’offre, une description de l’offre, etc.
Diagramme entité association
Le diagramme de la figure 3.3 illustre les tables construits ainsi que les relations qui existent entre eux.
Vue dynamique : diagramme de séquences
Dans cette section,nous présentons les diagrammes de séquences associés à notre application. Les diagrammes de séquences montrent les collaborations entre les objets selon un point de vue temporel en mettant l’accent sur la chronologie des envois de messages. Ainsi, Les diagrammes de séquences présentent une vue dynamique du système et la communication entre les couches. Dans ce qui suit nous présentons les diagrammes les plus importants de notre application.Le diagramme de séquence présenté par la figure 3.4 est relatif au scénario de l’authentification qui est détaillé comme suit : • Acteurs : les utilisateurs de l’application : le recruteur, l’administrateur et les candidats. • But : s’authentifier pour profiter des différentes fonctionnalités offertes par l’application. • Pré-conditions : L’utilisateur doit avoir un compte déjà créé. • Enchainement : – L’utilisateur demande l’accès au système. – L’utilisateur saisit les information : son identifiant et son mot de passe. – Le système vérifie l’existence de l’utilisateur dans la base de données. – Si l’utilisateur existe, le système affiche l’interface qui lui est relatif. • Enchainement alternatif : Si les champs ne sont pas valides, le système affiche un message d’erreur. • Post-condition : L’utilisateur doit avoir l’accès aux fonctionnalités.
|
Guide du mémoire de fin d’études avec la catégorie Spécification non formelles des besoins |
|
Étudiant en université, dans une école supérieur ou d’ingénieur, et que vous cherchez des ressources pédagogiques entièrement gratuites, il est jamais trop tard pour commencer à apprendre et consulter une liste des projets proposées cette année, vous trouverez ici des centaines de rapports pfe spécialement conçu pour vous aider à rédiger votre rapport de stage, vous prouvez les télécharger librement en divers formats (DOC, RAR, PDF).. Tout ce que vous devez faire est de télécharger le pfe et ouvrir le fichier PDF ou DOC. Ce rapport complet, pour aider les autres étudiants dans leurs propres travaux, est classé dans la catégorie Interface de l’espace administrateur où vous pouvez trouver aussi quelques autres mémoires de fin d’études similaires.
|
Table des matières
Introduction générale 1
1 Etude préalable
1.1 cadre général
1.2 Présentation de l’organisme d’accueil
1.2.1 Chiffres clés .
1.2.2 Les services offerts
1.2.3 Support et maintenance
1.3 Définition de la gestion des ressources humaines
1.3.1 Évaluer les besoins en ressources humaines
1.3.2 Rédiger les descriptions de tâches
1.3.3 Gestion des candidatures
1.4 Etude de l’existant pour la gestion des ressources humaines au niveau des candidatures
1.5 Problématique
1.6 La solution proposée
2 Analyse et spécification des besoins
2.1 Spécification non formelles des besoins
2.1.1 Spécification des besoins fonctionnels
2.1.2 Spécification des besoins non fonctionnels
2.2 Spécification semi-formelle des besoins
2.2.1 Identification des acteurs
2.2.2 Diagramme des cas d’utilisation
2.2.3 Diagrammes de séquences
3 Conception
3.1 Architecture globale
3.1.1 Présentation de l’architecture client/serveur
3.1.2 Les avantages de l’architecture client/seveur
3.2 Conception détaillée
3.2.1 Vue statique
3.2.2 Vue dynamique : diagramme de séquences
4 Réalisation
4.1 Environnement de travail
4.1.1 Environnement matériel
4.1.2 Environnement logiciel
4.2 Exposition du travail réalisé
4.2.1 Interface d’accueil
4.2.2 Interface d’authentification
4.2.3 Inscription d’un candidat
4.2.4 Interface de l’espace administrateur
4.2.5 Interface de l’espace recruteur
4.2.6 Interface de l’espace candidat
Conclusion générale
Bibliographie
Bibliographie et Netographie
Nétographie
A Annexe
Télécharger le rapport complet
