Vous êtes sur la page 1sur 35

CAHIER DES CHARGES

1. PRESENTATION DU PROJET

Le projet que nous sommes appelés à élaborer s’intitule « Développement


d’une application mobile de géolocalisation des hôpitaux sous la plateforme Android Cas de
la ville de Kinshasa ».

2. DESCRIPTION DU LA FUTURE SOLUTION

Kinshasa est la capitale de la République démocratique du Congo (RDC) avec


une population estimée pour cette année à 17.071.000 habitants sur une superficie de 1713
km2 [Web3_K].

Compte tenu de sa situation urbaine et de sa superficie, les kinois veulent un


logiciel qui leur permettra de rechercher un grand nombre d’hôpitaux de la ville province de
Kinshasa et connaitre l’itinéraire pour y parvenir.

Un utilisateur fait la recherche d’un hôpital grâce à son téléphone équipé d’un
système d’exploitation Android.

Les hôpitaux seront identifiés par leurs altitudes, longitudes, latitudes, image,
photo, numéro, avenue, quartier et un numéro de téléphone pour permettre à l’utilisateur de
contacter le service client de l’hôpital.

Un hôpital rend des services ou des tâches bien spécifiques. Ils sont situés dans
une ou plusieurs communes et les communes sont groupées dans les districts. Pour une bonne
organisation, les hôpitaux de Kinshasa sont dirigés par des responsables bien déterminés et
qui sont identifiables par leurs noms, post nom, prénom, sexe, etc.

Chaque utilisateur peut se géo localiser et connaitre sa position par rapport à un


hôpital. Il peut contacter (message ou appel) le service de réception de l’hôpital et s’informer
de toute les mises à jours grâce à son Smartphone

3. PRESTATIONS ATTENDUS

Notre application sera mobile et permettra ainsi de se localiser, de géo localisé


des hôpitaux de la ville de Kinshasa. En fonction de leur besoin et de leur localisation
géographique, l’application permettra à ses utilisateurs de trouver les hôpitaux les plus
proches, contacter aisément tous les centres de santé de la ville et faire des messages de
détresse en cas d’urgence.

Outre la localisation géographique des hôpitaux, les utilisateurs peuvent


également accéder à toutes sortes de renseignements ou informations à des fins utiles, telles
que les horaires d’accueil, la spécialité prise en charge, les tarifs, etc.

Disponible sur Smartphones et tablettes connectées à Internet, l’API proposera


automatiquement un itinéraire aux utilisateurs.

4. ORGANISATION

Nos intervenants :

 L’entreprise CRIA est le maitre d’ouvrage


 Rover solution est le maitre d’œuvre, son rôle est de fournir le produit a L’entreprise
CRIA

Organigramme du projet :
5. CALENDRIER DU PROJET

1. Identification et dénombrement des taches

Taches Durées/ Jour Désignations

A 1 Début du projet
B 5 Etude de cahier de charge
C 2 Phase analyse du domaine
D 3 Phase analyse de l’application
E 4 Phase de la conception
F 9 Implémentation du nouveau système
G 1 Livraison de l’application
H 4 Observation du nouveau système
I 1 Fin du projet

2. Ordonnancement des tâches, identification des précédentes et de suivantes :

Taches Durées/ Jour Désignations Précédents

A 1 Début du projet -
B 5 Etude de cahier de charge A
C 2 Phase analyse du domaine B
D 3 Phase analyse de l’application C
E 4 Phase de la conception D
F 9 Implémentation du nouveau système D, E
G 1 Livraison de l’application F
H 4 Observation du nouveau système G, F
I 1 Fin du projet H

3. Méthode MPM

Niveau 0 : A

Niveau 1 : B

Niveau 2 : C

Niveau 3 : D

Niveau 4 : E

Niveau 5 : F

Niveau 6 : G
Niveau 7 : H

Niveau 8 : I

Tâches critiques : A, B, C, D, E, F, G, H, I

Durée des travaux (Début à 0): 30

4. Tableau des dates

5. Chemin critique
ANALYSE DU SYSTEME
 ETUDE DE CAS
a. Description du problème

Le but de ce projet est de développer une application native mobile de


géolocalisation des hôpitaux de la ville province de Kinshasa. Cette application sera appelée
WAPI HOPITAL.

Le fonctionnement de Wapi hôpital est le suivant : avant toute utilisation,


l’utilisateur doit avoir un Smartphone Android et il doit installer l’APK de l’application dans
son téléphone.

Le logiciel permettra la recherche d’un grand nombre d’hôpitaux de la ville


province de Kinshasa et affichera l’itinéraire pour y parvenir.

Chaque utilisateur peut se géo localiser et connaitre sa position par rapport à un


hôpital. Il peut contacter hôpital par message ou appel.

Le logiciel permettra aussi de localiser un hôpital ou un centre de santé à


Kinshasa en fournissant toutes les informations nécessaires à l’utilisateur.

Il y aura la possibilité de retrouvé l’hôpital le plus proche de la position de


l’utilisateur et le traçage de la route vers l’hôpital.

 ANALYSE DU DOMAINE
 Diagramme de classes du domaine

 Identification des classes

Hôpital
Responsable
Utilisateur
Service
Détail
Réceptionniste
Kinois
 Conservation des classes pertinentes

Hôpital
Réceptionniste
Service
Personne
 Les associations pertinentes

Un utilisateur localise un hôpital ;

Un utilisateur peut contacter le service client de l’hôpital ;

Un réceptionniste appartient à un hôpital ;

Un hôpital rend des services.

 Les attributs
 Hôpital
 Nom,
 Altitudes,
 Longitude,
 Latitude,
 Image (photo)
 Adresse
 Un numéro de téléphone,
 Utilisateur
 Nom ;
 Post nom ;
 Prénom,
 Sexe,
 Adresse,
 Service
 Libellé
 Fonction
 Pavillon
 Réceptionniste
 Nom
 Post nom
 Prénom
 Sexe
 Dictionnaire des données
 Utilisateurs : Personne ou patient qui utilise le logiciel à l’aide de son
Smartphone ;
 Service : C’est une activité au sein de l’hôpital ;
 Hôpital : Etablissement ou l’on soigne les malades.
 Réceptionniste : La personne qui s’occupe de recevoir les clients dans
un hôpital etc...
 Illustration Du Diagramme Des Classes

 Organisation du diagramme des classes


 ANALYSE DE L’APPLICATION
1. Modelé d’interaction de l’application
a. Frontière de l’application

Notre application se limitera à afficher la position des hôpitaux de la ville


province de Kinshasa, elle permettra de retrouver l’itinéraire de l’hôpital le plus proche.

Le logiciel permettra de contacter l’hôpital en cas de besoin et les accordes


entre l’homme est l’hôpital sera géré dans cette api entre autre la demande d’une ambulance,
la demande de médecin a domicile.

b. Acteurs

Nous aurons deux acteurs qui vont interagir avec notre système:
 Utilisateur ;
 Service Client ou le réceptionniste

c. Les cas d’utilisations


a. Liste des cas d’utilisations
 Rechercher l’hôpital le plus proche;
 Tracer l’itinéraire;
 Contacter l’hôpital;
 Se géo localisé;
 Chercher un hôpital ;
 S’informer des services ;
 Mettre à jour les informations ;
 Recevoir les appels, SMS et email.
b. Diagramme des cas d’utilisations

c. Résumer des quelques cas d’Utilisations


 Se géo localiser :

Le système affiche la position de l’utilisateur sur la carte Google Maps

 Rechercher l’hôpital le plus proche

Le système affiche la position de l’hôpital le plus proche de l’utilisateur ;

 Tracer l’itinéraire :

Le système trace l’itinéraire de l’hôpital à partir de la position de l’utilisateur


 Rechercher un hôpital :

Le système affiche l’hôpital que l’utilisateur recherche;

 S’informer de mise à jour

Le système affiche les informations du jour.

 Contacter l’hôpital :

Le système permet à l’utilisateur d’être en contact avec le réceptionniste de


l’hôpital;

 Recevoir les appels, SMS et e-mail :

Le service client ou le réceptionniste répondra aux appels, SMS et e-mail des


utilisateurs

d. Les évènements initiaux et finaux

CAS D’UTILISATION EVENEMENT INITIAL EVENEMENT FINAL


Rechercher Affichage de l’hôpital le
En attente de la demande de
l’hôpital le plus plus proche par le
l’utilisateur
proche système
Géo localisation de
Se géo localisé Ouverture de l’application
l’utilisateur par le système
Demande de l’itinéraire Traçage de l’itinéraire
Tracer l’itinéraire
par l’utilisateur par le système
Demande de
Rechercher un Affichage de l’hôpital par le
rechercher un hôpital
hôpital système
Par l’utilisateur
S’informer des Sélection d’un hôpital Affichage des services de
services par un utilisateur l’hôpital par le système
Transmission du
Contacter Demande de contacter contact au service
l’hôpital l’hôpital par l’utilisateur clientèle par le système

Demande
Faire les mises à
d’information du jour Mise à jour effectuée
jour
par l’utilisateur

d. Les scenarios standards des quelques cas d’utilisation


1. se géo localiser
 Le système demande à l’utilisateur de lancer l’application ;
 L’utilisateur lance l’application ;
 Le système géo localise l’utilisateur ;
2. Tracer l’itinéraire
 L’utilisateur demande l’hôpital le plus proche ;
 Le système géo localise l’utilisateur ;
 Le système affiche l’hôpital le plus proche ;
 L’utilisateur demande l’itinéraire ;
 Le système trace l’itinéraire
3. Rechercher un hôpital
 Demande de recherche d’un hôpital Par un utilisateur
 Le système lui demande de saisir le nom de l’hôpital ;
 L’utilisateur saisi le nom de l’hôpital ;
 Le système affiche l’hôpital
4. S’informer de mise à jour ;
 Demande d’information du jour par l’utilisateur ;
 Le système affiche les informations du jour.
5. Contacter l’hôpital ;
 Demande de contacter le service client de l’hôpital par l’utilisateur
 Le système demande à l’utilisateur de choisir le mode du contact.
 L’utilisateur choisit le mode
 Le système lance un appel au service client de l’hôpital.
6. Rechercher l’hôpital le plus proche
 L’utilisateur ou le patient lance l’application
 L’utilisateur demande l’hôpital le plus proche
 Le système géo localise l’utilisateur
 Le système affiche l’hôpital le plus proche

e. Scenarios alternatives et des séquences d’exceptions


1. Cas d’activités contacter hôpital
 Message vide
 Forfait insuffisant
 Réseau indisponible
2. Cas d’activités tracé Itinéraire
 Les données mobiles ne sont ouvertes ;
 Pas de connexion.
f. DIAGRAMME DES SEQUENCES
1. Cas d’utilisation Rechercher l’hôpital le plus proche

2. Cas d’utilisation Tracer l’itinéraire


3. Cas d’utilisation : Rechercher un hôpital

g. DIAGRAMME D’ACTIVITES POUR LES CAS D’UTILISATIONS


CPMPLEXES
1. Cas d’utilisation tracé itinéraire
a. demande de l’hôpital plus proche ;
b. localisation de l’utilisateur ;
c. calcul de la distance entre la position de l’utilisateur et tous les
hôpitaux
d. Affichage de l’hôpital plus proche ;
e. Tracer l’itinéraire.
f. pas de connexion internet
g. GPS désactivé
h. Organisations des cas d’utilisations

2. Modèle de classes de l’application


a. Spécification de quelques interfaces

Figure Ecran principal


Notre écran principal comprend trois boutons à savoir :

 Bouton position utilisateur : permet à l’utilisateur ou le patient de visualiser sa


position et la position de quelques hôpitaux sur la carte GoogleMaps.
 Bouton hôpital le plus proche : au clic de ce bouton, l’utilisateur l’application verra
une liste de trois hôpitaux plus proche de lui ou de sa position.
 Bouton recherche : Ce bouton permettra à l’utilisateur ou à un patient de rechercher
un hôpital.

Figure. Interface de la position de l’utilisateur

Cette interface, ci-dessus, permet à l’utilisateur de voir sa position sur une carte
GoogleMaps et cela lui permet aussi de connaitre l’adresse de là ou, il se trouve.

Figure Interface hôpital plus proche


L’interface de l’hôpital le plus proche, aide à l’utilisateur de voir une liste des
hôpitaux qui sont plus proche de lui, elle permet de tracer l’itinéraire depuis la position de
l’utilisateur vers l’hôpital sélectionné. Grace à cette interface, l’utilisateur pourra contacter
l’hôpital

b. Modèle de classes d’application


SPECIFICATION INITIALE
1.1. Présentation du sujet
Le sujet qui a porté notre choix est la Mise en place d'une application de gestion
d'achat des livres du prof Saint-Jean DJUNGU.

Notre idée consiste à développer une application qui permet aux personnes de
n’importe quel pays, n’importe quelle civilisation et culture de se procurer un ou plusieurs
livres dont l’auteur est le Professeur Docteur Saint Jean DJUNGU.

1.2. Elaboration du concept


1.2.1. A qui l’application est – elle destinée ?
Notre application est destinée à toute personne qui désire lire et avoir le livre du prof
DJUNGU en caractère informatique. Il y aura une partie qui sera destiné au service concerné
de l’auteur pour des éventuels mises à jour.
1.2.2. Quels problèmes l’application résoudra – t – elle ?

Aujourd’hui pour avoir l’ouvrage du professeur, il faut soit passé par l’amazone pour
commander un livre et dans cette plateforme les coûts du livre est énorme et il faut attendre
des jours pour s’en procurer ; sur ce la plus part des personnes entre autre les étudiants préfère
l’acheter auprès de leur chef de promotion ou du service compètent du professeur, sauf que
nous avons constaté que parfois le chef de promotion ne sont pas là et ils sont à plusieurs
reprise en rupture de stock et le service que le prof a mis en place sont souvent absent, sur ce
nous allons mettre en place une application mobile qui permettra aux individus à acheter et à
commander les ouvrages de l’auteur sans se préoccuper de sa position géographique, ni de la
distance, l’application permettra l’achat en ligne et à avoir une notification pour le
récupération.
1.2.3. Conditions d’utilisation

Après son téléchargement dans une boutique en ligne, elle sera installée dans un
smartphone et tournera dans un téléphone Android, cette application nécessitera une
connexion internet pour faire l’achat d’un livre.

1.2.4. Quand l’application est – elle attendue ?

Pour la réalisation de ce projet, toutes les contraintes tant au niveau budgétaire que
ressources nécessaires sont d’une importance très capitale afin que l’application soit réalisée
d’une bonne manière et être livrée au moment très opportun.
La nécessité de ce projet dépend du respect des engagements conclus entre les deux
parties (les techniciens et les experts métier) quand en ce qui concerne la résolution des toutes
les exigences et contraintes possibles ci – haut énumérées.

L’application sera disponible au mois d’Avril 2021.

1.2.5. Pourquoi l’application est-elle attendue ?

Cette application est attendue pour faciliter l’achat rapide des ouvrages de
professeur, elle vient diminuer le temps de traitement de taches et l’encombrement des
étudiants dans le bureau des assistants.
Elle augmentera le taux de rentabilité et gain sur le plan financier, elle permettra au
professeur de bien suivre le processus des ventes de ses livres.
1.2.6. Fonctionnements de l’application

Pour son développement nous utiliserons une architecture à trois niveaux afin de
séparer la logique applicative, la logique métier, les services (accès aux données) et
l’interface.

1.3. Phase préparatoire


1.3.1. Etude d’opportunité

 Contexte
Nous avons besoin de résoudre le problème de lenteur a l’achat des ouvrages
du professeur, éviter les encombrements dans le bureau du prof ou des assistants.
Cette application concernera toute personne informaticien et non informaticien
qui veut apprendre et amoureux des livres de pouvoir se procurer librement et simplement
l’ouvrage du professeur Saint-Jean.
Le logiciel permettra à l’administrateur ou au service concerné du professeur
de faire des mises à jours, de publier la disponibilité des livres.

 Etat des lieux de l’existant


Tous se fait manuellement, au niveau de la faculté et du département de math-
info. L’étudiant qui désire acheter un livre du professeur, doit contacter son chef de promotion
ou aller voir les assistant dans leur bureau.
Après avoir montré son désir de se procurer un livre, l’assistant ou le chef de
promotion notera sur un cahier ou un registre l’identité de l’étudiant, ensuite il récupèrera
l’argent entre les mains de celui-ci (étudiant) et remettra l’ouvrage a l’acheteur.
Les livres du professeur se trouve dans le bureau du professeur et ils sont rangé
en plusieurs rayons.

 Quelques fonctionnalités
L’application permettra aux étudiants de s’identifier, de créer un compte et
faire l’achat d’un livre.
Elle permettra de voir toute les ouvrages publier par le professeurs Saint – Jean
DJUNGU, elle permettra de lire le résumé de chaque livre, de contacter le service de vente du
livre et de payer les livres.

 Enjeux
Notre logiciel sera professionnel pour le professeur Saint – Jean DJUNGU, il
aura quelques enjeux suivants :
 Le logiciel aura une approche simple et conviviale c.à.d. tous les données seront très
faciles à manipulées et à comprendre. Les utilisateurs l’utiliseront facilement.
 Il permettra à créer un compte pour chaque type d’utilisateur.
 Le logiciel permettra la planification de rendez-vous de payement de frais de livre.
 Ceux qui utiliserons cette application gagnerons en temps record pour l’achat du livre.
 Cette application permettra au professeur de maximiser ses recettes et en vendre au
maximum ses livres et ses ouvrages.

1.3.2. Etude de faisabilité

a) Besoin
Le professeur Saint-Jean DJUNGU a besoin d’une application mobile
professionnelle qui permettra aux gens ou à toute personne d’acheter ses ouvrages pour
maximiser ses revenus.
L’application permettra à tous de commander l’ouvrage peu importe la position
de la personne ou sa distance géographique, elle permettra aussi de payer en ligne un ouvrage
et de recevoir un fichier PDF du livre.

b) Objectifs

Cette application est entendue pour lutter contre la lenteur d’exécution des
tâches, lutter contre le vol d’argent de support par le chef des promotions et minimiser le coût
de déplacement pour payer un livre.
Cette application sera un nouveau système informatique et elle remplacera le
système manuel longtemps utiliser, elle minimisera le cout d’achat des matériels (stylo, cahier
etc.) pour l’enregistrement des chaque information au sein de l’entreprise.
Parmi tant d’objectifs, le dernier est de faire gagner du temps de travail de
gestionnaire et permettre aux personnes (acheteurs) de gagner plus du temps pour payer un
ouvrage.

c) Présentation de l’existant

L’étude de l’existant, est l’analyse de fonctionnement du système en vigueur.


Elle s’intéresse à poser ce qui est lié physiquement a ce système et cherche à poser des
principes de base à cette étude. Et faire sortir des anomalies constatées afin de pouvoir
prendre des décisions ou critiques du système.
Pour la gestion de l’achat d’un livre auprès d’un chef de promotion ou d’un
assistant, ils disposent des matériels ci-après :
1. Moyen matériel
 Un carnet de rapport
 Un cahier d’enregistrement de l’acheteur
 Un style
 Une table
 Un ordinateur
2. Description de l’ordinateur:

Marque : Lenovo

Processeur : Intel (®)

Vitesse : 3ghz

Mémoire (RAM) : 8GO

Claviez : Azerty

Souris : PS2

Disque dur 1 To

2. 3. Etude des personnes


L’analyse des moyens humains est nécessaire pour mieux comprendre les
qualifications du personnel sensé travaillé au sein du service concerné par l’application.

Les moyens humains utilisés pour le service de nouveau-né au centre


hospitalier le cœur sont :
Niveau
Poste Effectif Spécialité Fonction Expérience
d’étude

Assistant 1 Licencié informaticien 3 ans


Assistant

Chef de
1 L1 Informatique 1 ans
promotion CP
Chef de 1 ans
promotion 1 L1 Informatique CPA
Adjoint
d) Critique de l’existant
L’achat des ouvrages se passe normalement mais l’enregistrement des
informations de l’acheteur se fait manuellement et très lent;

Ici on tient compte que des étudiants sauf qu’il oublie qu’un corps scientifique
ou un chef d’entreprise peut se procurer d’un ouvrage scientifique informatique de l’auteur
Saint – Jean DJUNGU, cette méthode n’est malheureusement prévue.

e) Proposition de la solution

Après avoir mis en évidence les imperfections du système existant, il est


maintenant question de recherche les moyens existants, d’extirper les lacunes en proposant
une solution efficace.
Cette solution consiste à mettre en place un logiciel ou application informatique afin de
permettre l’achat des ouvrages du professeur Saint – Jean DJUNGU, cette application
professionnelle permettra de payer les livres, d’entrer en contact avec le service des ventes des
ouvrages, de lire le résumé de chaque livre de l’auteur, de voir le prix et de télécharger le
fichier PDF.

2.1.1. Cahier des charges

a. Présentation du projet
Nous voulons mettre une application professionnelle qui va gérer l’achat des
ouvrages de l’auteur Saint- Jean DJUNGU.

b. Description de la solution
Le professeur Saint – Jean DJUNGU veut une application mobile
professionnelle pour la vente de ses ouvrages.
Pour faire l’achat d’un ou plusieurs livres, la personne se dirigera au service
compètent du professeur ; elle donnera ses identités entre autre son nom, post-nom, prénom
etc. chaque personne est distinguée par sa catégorie car le prix d’un livre est fixé par la
catégorie de la personne. Nous avons 3 catégorie de personne : catégorie étudiant, catégorie
corps scientifique et catégorie corps professionnel.
Un corps scientifique (chercheur) ne payera pas comme les étudiants et non
plus comme un corps professionnel (chef d’entreprise ou employé), les étudiants bénéficieront
d’une réduction.
Les livres sont groupés en type (réseaux, programmation, méthodes,
Algorithmes et systèmes) et sont identifié par leur titre, date d’édition, maison d’édition, code
SDN, résumé et nombre de page.
Le nouveau système permettra à un étudiant de créer un compte, de commandé
un ou plusieurs ouvrages, d’être en contact avec le service compètent du prof qui gère les
ventes des supports et de permettre à toute personne de lire le résumé de chaque ouvrage.
Le payement d’un ouvrage se fera soit par mobile Banking ou en espèce auprès
d’un agent après avoir commandé.

c. Prestations attendues

A la fin de la conception et à la livraison de notre, nous mettrons en place


certains documents expliquant par exemple le fonctionnement de l’application, les différentes
conditions et exigences d’utilisation du logiciel (les performances des matériels
informatiques, l’environnement de travail (système d’exploitation) et autres, les ressources
humaines compétentes pour une bonne utilisation de l’application vu qu’elle sera utilisée dans
un smartphone mobile.

d. Organisation

L’application aura une équipe des personnes qui s’occuperont de sa


maintenance et ses mises à jours, il y aura un mécanisme pour permettre aux utilisateurs de
communiqué avec les gestionnaires de l’application.

3.
ANALYSE DU SYSTEME
2.1. Analyse du domaine
2.1.1. Délimitation du domaine
Notre champ d’application se limite à faire une commande d’un ouvrage,
chaque utilisateur pourra payer son argent grand à M-PSA, TIGO CASH, ARITEL MONEY
etc.
L’application présentera au public le résumé de chaque ouvrage et elle aidera
les étudiants être en contact avec le service compètent des ventes des livres du professeurs
Saint – Jean DJUNGU.

2.1.2. Modèle de classes du domaine


1) Identification des classes
Compte tenu de notre énoncé édité ci-haut dans le premier chapitre, dans la
rubrique cahier de charge, nous avons pu avoir les entités suivantes
 Personne
 Etudiant
 Chercheur
 Corps professionnel
 Ouvrage
 Gestionnaire
 Type ouvrage
 Catégorie personne
 Livre
 Corps académique

2) Conservation des classes pertinentes


 Personne
 Etudiant
 Corps professionnel
 Ouvrage
 Type ouvrage
 Corps académique

3) Dictionnaire des données


 Personne : c’est toute individus qui a besoin d’acheter un ouvrage.
 Livre : le livre qui est en vente.
 Etudiant : personne ne qui fait les études supérieures et suit les cours d’une
université, dans le cadre de notre application c’est un acheteur du livre
 Corps scientifique : professeur, ingénieur ou docteur.
 Corps professionnel : est un ensemble d’espace dans un appartement
 Type ouvrage : c’est la catégorie d’appartient un livre

4) Identification des associations


 Une ou plusieurs personnes commandes des livres
 Un livre a un type de livre

5) Identification des attributs


 Personne
- Nom,
- Post nom
- Prénom
- Téléphone
- Sexe
 Livre
- Titre
- Résumé
- Nombre page
- Maison d’édition
- Code SDN
 Étudiant
- Matricule
- Nom,
- Post nom
- Prénom
- Téléphone
- Sexe
- Promotion
- Département
- Faculté
- Université
 Corps scientifique
- Domaine de recherche
- Spécialité
- Université d’attache
- Nom,
- Post nom
- Prénom
- Téléphone
- Sexe
 Corps professionnelle
- Nom
- Post nom
- Prénom
- Téléphone
- Sexe
- Entreprise
- Fonction
- Téléphone

 Type ouvrage
- Désignation
- Commentaire

6) Diagramme de classes

Figure II.2. Diagramme des classes

7) Organisation du diagramme des classes avec opérations


Figure II.3. Organisation de diagrammes de classes avec méthodes et héritages

8) Groupement de classe en package


Nous aurons deux packages :
 Personne : personnes, étudiant, corps scientifique, corps académique
 Ouvrage : Livre et type livre

2.1.3. Modèle d’états transitions


Nous n’avons pas de diagramme d’état transition, parce que aucune classe de
notre diagramme de classe du domaine a un comportement cyclique.

2.2. Analyse de l’application


2.2.1. Frontière du système
Notre application gèrera que les ventes des livres du professeur Saint – Jean
DJUNGU, elle permettra à une personne de créer un compte, de faire un choix du livre, de
pouvoir lire le résumé de chaque livre et même de payer le livre.

a. Identification des acteurs


Les acteurs principaux qui utiliseront notre système sont les suivants :
- Utilisateur ;
- Administrateur;
b. Recensement de cas d’utilisation
Signalons que tous les besoins fonctionnels possibles du système sont toujours
couverts par l’ensemble des cas d’utilisation. Après recensement des cas d’utilisation, les
retenus sont ceux qui suivent :
- S’authentifier
- Payer livre ;
- Recevoir les annonces ;
- Lire résumé ;
- Vérifier la disponibilité d’un livre ;
- Contacter l’administrateur ;
- Publier un livre.
c. Résumé des cas d’utilisation
 S’authentifier :
Le système permet à l’utilisateur de s’authentifier pour bénéficier de toute les
fonctionnalités du système
 Payer livre
Le système permettra à un acheteur de payer son livre librement et tranquillement.
 Vérifier disponibilité du livre
Il y a toujours rupture de stock, et le logiciel informera a l’acheteur de la disponibilité de
chaque livre, les nombres de livre en stock, son prix etc.
 Contacter
L’acheteur du livre aura besoin de contacter son vendeur, l’application assurera la
communication par appel, sms et même E-mail entre l’acheteur et le vendeur du livre
 Lire le résumer
Chaque personne qui veux se procurer un livre, aura la possibilité de lire le résumer du
livre de son choix, voir sa table de matière, quelques points important du livre.

 Recevoir annonce
A chaque publication d’un livre ou ouvrage par l’auteur, les utilisateurs de l’application
seront automatiquement informer.
 Publier annonce
Publier annonce sera le cas d’utilisation de l’administrateur, il mettra en valeur les
ouvrages, il fera les mises à jour etc.

d. Description des cas d’utilisation


Figure II.6 : Diagramme de cas d’utilisation.

e. Les évènements initiaux et finaux

Cas d’utilisation Evènement initial Evènement final


S’authentifier Le système demande à L’acheteur s’authentifie
l’acheteur de s’authentifier pour se connecter au
système
Payer livre L’acheteur demande de Le système valide le
payer un livre payement de l’acheteur
Vérification de la le système afficher tous L’utilisateur voit les livres
disponibilité du livre les livres disponibles disponibles, son prix et sa
quantité
Lire le résumer Demande de lire le Le système affiche le
résumer du livre par résumer du livre
l’utilisateur
Contacter l’administrateur L’application permet à Le système contacte
l’acheteur ou utilisateur l’administrateur par l’action
d’être en contact avec le de l’utilisateur ou acheteur
service de vente des livre
Recevoir annonce L’utilisateur demande de Le système affiche les
recevoir les annonces annonces du jour a
l’utilisateur

f. Scenario standard de quelques cas d’utilisations


 S’authentifier
 Le système lui demande de saisir le login
 L’utilisateur saisi son login
 Le système lui demande d’introduire son mot de passe
 L’utilisateur introduit son mot de passe
 L’utilisateur valide ses informations
 Le système accepte le login et le mot de passe
 Le système affiche le menu principal de l’application
 Payer livre
 L’utilisateur se connecte au système
 Le système affiche le menu principal
 Le système affiche tous les livres disponibles
 L’utilisateur sélectionne un livre
 Le système lui demande d’entré le nombre voulu
 L’utilisateur introduit le nombre
 Le système lui demande de saisir la somme à payer
 L’utilisateur introduit le montant
 Le système lui demande d’introduire son code M-PSA ou autre
 L’utilisateur introduit son code
 Le système demande à l’utilisateur de valider
 L’acheteur valide
 Le système envoi un sms de confirmation

 Vérifier la disponibilité d’un livre


 L’utilisateur s’authentifie au système
 Le système affiche le menu principal
 L’utilisateur demande la disponibilité d’un livre
 Le système affiche la disponibilité du livre
 Afficher le résumer
 L’utilisateurs s’authentifie au système
 Le système affiche le menu principal
 Demande le résumer d’un livre;
 Affichage du résumer par le système ;
g. Diagrammes de séquence
a) Diagramme de séquence pour le cas d’utilisation « S’authentifier »
Figure II.7 : Diagramme de séquence pour le cas d’utilisation « S’authentifier ».

b) Diagramme de séquence pour le cas d’utilisation « Afficher résumer »


Figure II.8 : Diagramme de séquence pour le cas d’utilisation « Afficher
résumer ».

c) Diagramme de séquence pour le cas d’utilisation vérifier disponibilité d’un livre.


Figure II.9 : Diagramme de séquence pour le cas d’utilisation « Vérifier disponibilité
d’un livre ».

h. Diagrammes d’activités pour les cas d’utilisation complexes


a. Cas d’utilisation « payer livre »
1. Demande du formulaire de paie
2. Introduit le montant
3. Valider le montant
4. Le montant est insuffisant
5. Impression du facture

Figure II.10 Diagramme d’activité du cas d’utilisation payer livre

i. Organisations des cas d’utilisations


Figure II.11 organisation du diagramme de cas d’utilisation

j. Modèle de classes de l’application


a. Spécification des quelques interfaces
Figure II.12. Menu principal
L’interface de connexion a un boutons le bouton valider, il permet d’entrer
dans l’application et de bénéficier de toutes ses fonctionnalités et enfin l’astuce mot de passe
oublié, qui permet à l’utilisateur de récupérer son mot de passe.

Figure II.13. Interface menu principal

C’est le menu principal, il comprend quatre boutons, qui sont :


 Accueil : permet toujours de revenir à la page d’accueil de l’application
 Payer : en cliquant sur ce bouton, l’utilisateur a la possibilité de voir la disponibilité
du livre, voir le résumer du livre et faire tranquillement son achat.
 Contact il permet aux administrateurs du logiciel et a l’utilisateur d’être en contact
 Liste : il liste tous les livres disponibles dans l’application

b. Modèle de classe de l’application

Figure II.14. Diagramme des classes de l’application

Vous aimerez peut-être aussi