Vue statique : Diagramme de classes
Nous nous focalisons sur l’aspect architectural de l’application. Cette phase a pour but de concevoir les schémas généraux qui permettent la modélisation et la description d’une manière non ambiguë du fonctionnement désiré de l’application. Dans ce chapitre deux vues conceptuelles seront décrite. La première donne une vue globale de l’architecture tandis que la deuxième offre une vue détaillée en se basant sur le langage UML (Unified Modeling Language).
Architecture de l’application
Dans les phases préliminaires du développement d’une application ou de la refonte d’un système d’information, la définition de l’architecture technique consiste à faire les choix de technologies et d’organisation de composants logiciels les plus adaptés aux besoins et aux contraintes de l’organisation d’accueil. Ces choix sont ensuite relayés au sein de notre projet, guidant la conception et permettant la transformation d’un modèle fonctionnel en application performante et robuste. 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 de ses 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 composantes logicielles, à savoir un logiciel serveur et un logiciel client s’exécutant 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 de compromis 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/serveur
Pour le développement de notre application nous avons opté pour l’architecture client/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é : les données du serveur sont gérées sur le serveur de façon centralisée. Les clients 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.
Guide du mémoire de fin d’études avec la catégorie spécification des besoins non fonctionnels |
É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 diagramme de classes où vous pouvez trouver aussi quelques autres mémoires de fin d’études similaires.
|
Table des matières
Introduction générale
Chapitre 1 Etude préalable
1.1 Introduction
1.2 Etude de l’existant
1.3 Critique de l’existant
1.4 Solution proposée
1.5 Spécifications
1.5.1 Spécification des besoins fonctionnels
1.5.2 Spécification des besoins non fonctionnels
1.5.3 Identification des acteurs
1.5.4 Les diagrammes des cas d’utilisation
1.5.4.1 Cas d’utilisation préliminaire
1.5.4.2 Cas d’utilisations détaillés
1.5.4.3 Cas d’utilisation «S’authentifier »
1.5.4.4 Cas d’utilisation «Gérer les comptes »
1.5.4.5 Cas d’utilisation «Gérer les candidatures
1.5.4.6 Cas d’utilisation «Gérer les établissements »
1.5.4.7 Cas d’utilisation «Gérer les filières»
1.5.4.8 Cas d’utilisation «Gérer le calendrier du concours»
Chapitre 2 Conception
2.1 Introduction
2.2 Architecture de l’application
2.2.1 Présentation de l’architecture client/serveur
2.2.2 Les avantages de l’architecture client/seveur
2.3 Conception détaillée
2.3.1 Vue statique : Diagramme de classes
2.3.2 Vue dynamique : les diagrammes de séquences
2.3.2.1 Diagramme de séquence système du cas d’utilisation « S’authentifier »
2.3.2.2 Diagramme de séquence système du cas d’utilisation « consulter un compte »
2.3.2.3 Diagramme de séquence système du cas d’utilisation «créer un compte»
2.3.2.4 Diagramme de séquence système du cas d’utilisation « postuler une candidature»
2.3.2.5 Diagramme de séquence système du cas d’utilisation « consulter les établissements »
2.3.2.6 Diagramme de séquence système du cas d’utilisation « affecter un établissement à une filière»
Chapitre 3 Réalisation
3.1 Introduction
3.2 Environnement de travail
3.2.1 Environnement matériel
3.2.2 Environnement logiciel
3.3 Création de la base de données
3.4 Implémentation
3.5 Les interfaces de l’application
3.5.1 Interface d’accueil
3.5.2 Interface d’authentification
3.5.3 Interface d’inscription
3.5.4 Interface « cursus »
3.5.5 Interface « postuler la candidature »
3.5.6 Interface « imprimer le formulaire »
3.5.7 Interface « valider la candidature »
3.5.8 Interface « affecter score »
Conclusion générale
Webographie
Annexes
Télécharger le rapport complet